В общем, писал я себе, писал прогу, а тут на тебе старый знакомый USBD_malloc. Думал раньше, что обойду его, а нет, настиг проклятый. Данная тема является продолжением Эпопеи в двух частях - Как меня задрали USB дрова от разработчиков STM.
А теперь ближе к делу.
Разбираясь в неполадках передачи по USB(висит в выделенном цикле, хотя в первый цикл проходит(повезло?)) в нижепоказанной функции, узрел что TxState содержит какое то невероятное число.

Думаю, что это неправильная инициализация указателя pClassData. Скорее всего он указывает на кусок мусора. Потому что собственно он инициализируется вот так(для тех кто в танке и не стал читать ссыль на предыдущую часть Эпопеи):

Сам малок выглядит вот так:

Как все успели заметить - это гавнокод(КО не дремлет). В связи с этим, хочу решить проблему иным способом, так чтобы работало всё.
Попробовал создать статическую переменную типа структуры USBD_CDC_HandleTypeDef(на нестатическую компилятор ругается при линковке, дескать узрел где то чуть ли не сотню дубликатов этого типа там, где он и не используется даже - явный тупняк):

Также убрал малок:

Работать это конешно не стало, как и предполагалось, всё тоже самое что и до замены малока.
Как бы решить эту проблему, подскажите)
P.s. На буржуйском форуме пишут про баги для STM32F4 Discovery. Якобы явное приведение типа указателя к void* и расширение heap поможет. Сомнительно. Но я к сожалению до понедельника не смогу удостовериться, так как прибор на работе

Update
И кто-нибудь сможет ответить на вопрос, почему если я создам глобальную (не статическую как показано выше) переменную типа USBD_CDC_HandleTypeDef, то вылетают такие ошибки:

что за хрень? в данных файлах нету никакого объявления USBD_CDC_Handle и уж тем более не подключены хедеры с файлами, где эта переменная объявлена.

Сообщение отредактировал Still Enemy - Aug 30 2015, 06:31

Это как раз вполне нормально. Любое выделение памяти вернет память с мусором. Заполнить его после этого разумными данными - задача программиста.
Ругань была совершенно справедливой, это явный ваш тупняк. Вы пытались определить переменную в заголовочном файле. Заголовочный файл включается в несколько исходных файлов (единиц копиляции) методом тупой текстовой подстановки. Получилось, что вы определили одну и ту же переменную в нескольких единицах компиляции. Компилятор понятия не имеет о существовании других единиц компиляции, поэтому честно создал такую переменную в каждой единице. И линкер получил кучу переменных с одинаковым именем. Когда вы добавили static, вы получили еще более веселый результат - вы получили в каждой единице компиляции свою переменную, которая не видна из других единиц компиляции. То есть каждая единица компиляции работала со своей копией переменной. Если смотреть углубленно - то ваш код при этом должен был работать, поскольку прямое обращение к этой переменной у вас происходит только в одном файле, там, где ее адрес присваивается указателю. В остальных местах обращение идет только через указатель и попадает в ту же самую переменную. Остальные копии этой переменной выкинул оптимизатор. Но в общем случае это говнокод еще похуже исходного.

Выкиньте ваше . В том файле, где находится строка объявите глобальную переменную и присвойте ее адрес После чего на всякий случай закомментируйте USBD_static_malloc чтобы компилятор ругался на все места, где она еще может использоваться.

Однако это скорее всего не поможет. Проблема не здесь. Исходный код с USBD_static_malloc() должен работать, если из него выкинуть free(p).

Ну я же не такой тупой) я посмотрел, что далее в этой же функции, после разименования указателя, идёт заполнение горемычной структуры.


А разве код(нижеприведённый) не должен спасать ситуацию?


Согласен, просто сделал первое, что пришло на ум)


Херога. Если при разыменование указателя всё нормально происходит, значит указатель портится в процессе выполнения проги. Это осложняет дело.

Нет. Он не позволяет повторное включение заголовочного файла в одну единицу трансляции. От включения в разные единицы трансляции он защитить не может и не должен.

Кароч это дно полное. Оказывается указатель pCDC в функции CDC_Transmit_FS "уничтожается" (не знаю даже как назвать это) знаете кем? Не угадали. ОПТИМИЗАТОРОМ. На Hige - Size.
Пруфф.

Картинка вообще зачётная, такого оптимизирования я еще не видел. Я могу конешно посетовать на то, что я и сам гавнокодер и оптимизатор на мой гавнокод реагирует однозначным гавнодействием. Но так чтобы игнорировать банальное создание указателя и разыменование, на такое я в осадок выпал. Более того скажу, иногда оптимизировался код на столько отлично, что указатель pCDC указывал вообще на левую структуру, жаль не смог запечатлеть этот момент)
Вывод: снизил оптимизацию на Medium и радуюсь. НО если кому не сложно, объясните где я накосячил с кодом, что всё пошло именно по такому пути( у меня есть конешно один вариант на этот счёт: я указатель hUsbDevice_0 не передаю в функцию аргументом, а беру его извне(он объявлен в том же хедаре как глобальный указатель, что и данная функция) и собственно из-за этого оптимизатор указатель "уничтожает")? Всё таки оптимизатором нужно считаться, хоть чуть-чуть.

Добро пожаловать в реальный мир. Суть его такова, что отладчик корректно показывает буковки-цифирки только при низких уровнях оптимизации.
Правильно написанный код при этом работает с любой оптимизацией. Понимать, как именно он работает, приходится по асм-листингу.

А какое содержимое отладчик показывает в h_UsbDevice_0->pClassData? И отлаживаться нужно бродя по дизассемблерному тексту, да.

pCDC заменил на pTrans


Сообщение отредактировал Still Enemy - Aug 31 2015, 12:53

И? Вы же видите, что никто эти данные не затер. Когда понадобится, этот указатель окажется в pCDC. pCDC будет размещен в R7. Сейчас R7 пока занят чем-то другим. Включите оконо дизассемблера, не бойтесь. Походите по шагам в нем.

В том то и дело, что я не боюсь) Прошел я по шагам на дизасемблере эту строчку(если я вас правильно понял конешно).
Пруф

Не, нужная строчка дальше. После текущей строчки в R7 будет жить offset, сейчас в ней мусор а в конце этого цикла окажется, вероятно, pTrans. pCDC в этот момент еще просто не существует.

Я извиняюсь, что ввел вас в заблуждение. Но я pCDC заменил на pTrans(я об этом отписывался ранее)

В таком случае, вероятно, ошибся отладчик. По приведенному отрывку мне кажется, что pTrans он загрузил в R8, а показывает R7.

Советую перейти на libopencm3, там таких косяков нет.

Дайте подумать,пожалуй, нет. Сдача проекта в конце сентября, проект не больно маленький. Разбираться во всех этих вещах по новой мне удовольствия не доставит. Да и вообще, нет уверенности, что в вашем libopencm3 не будет других проблем.

Сообщение отредактировал Still Enemy - Sep 2 2015, 11:30