често забелязвам разни бъгчета и обикновено ги подминавам, ама ще взема да ги събирам в тая тема...

файл: stm32f2xx_ll_usb.c
функция: HAL_StatusTypeDef USB_FlushTxFifo (USB_OTG_GlobalTypeDef *USBx, uint32_t num )

Евала!

В коя среда за програмирване. За кой проц- ако има значение?
И ако има някакво решение- в случая си го писал де.

В случая тоя бъг касае всички арм на ST и всички среди. То по принцип библеотечката на ST е обща.
Специализиране са само хедърите на фамилиите.... и там съм мяркал доста "печатни" и copy-paste грешки
Нищо сериозно и аз правя подобни грешки... просто като сравнявам моя код с техния и се виждат разликите. А като мине известно време забравям и хайде пак сравнявай с дейташит... Та затова в тая тема ще почна да си водя записки

Добра идея. Аз също го правя.

Извинявам се за офф-топика, ама нека на обобщаваме толкова генерално - тук говорите за StdPeripheral libraries на STM.
Има още няколко подобни по функционалност (хардуерна абстракция за ST) библиотеки, за които това може би не се отнася (например - libopencm3)

Е какъв е проблема, кой каквито бъгове в файловете намира да пише, пък дали ST са го проспали или някой "свободен", какво значение има?

ъхъ, което сега го прекръстиха на "STM32Cube Firmware Package"


Не бях чувал за libopencm3... някой ден ще ги разгледам по-подробно... и да това с USB-то не се отнася за тях, най-малкото не виждам да имат USB стек

То те като цяло нямат почти нищо завършено. Много в начална фаза са нещата, да видим дали ще го добутат до някъде. За добро или лошо, на тоя етап само ST дават пълни библиотеки с цялата условност, че кода им е далеч от перфектния и в много случаи даже е проблемен за ползване.

Относно куба на ST, аз се зарових преди седмица по-дълбоко в комуникационните драйвери (SPI, UART). Лошо. Опитали са се да вдигнат малко нивото на абстракция, опитали са се да прибавят някаква функционалност за вграждане в ОС... ама всичко е един голям турлюгювеч... според мен де. Спрели са някъде в нищото, нито са лоу-левел драйвери, нито истински комуникационни драйвери. Заебах ги засега.

По-завършено и работещо? Примерно HAL-а на чибито има почти всичко, и засега не съм го хващал в издънка.


Хм, стек не знам дали имат, но ти си дал бъг в драйвера за работа с USB контролера. Такова си имат, и за мен са много по-добре написани от стм-ските:
"libopencm3\examples\stm32\f4\stm32f4-discovery\usb_cdcacm":

поредната гадинка:

файл: stm32f2xx_ll_usb.c

функция: HAL_StatusTypeDef USB_HC_Halt(USB_OTG_GlobalTypeDef *USBx , uint8_t hc_num)


Тоя if трябва да проверява дали ендпоинта е control или bulk (непериодичен) и ако е така се гледа дали има място в непериодичното фифо, иначе периодичното.... Само че който е писал кода го е написал с оная си работа.
Всъщност не е само тоя if... цялата функция е пълна боза и не отговаря на написаното в чаршафите...



Тъй де... те така или иначе гледат грешно фифо, кво значение има дали го гледат "преди" или "след"

Ами имам чувството, че всички УСБ стекове са така. Написали нещо, то светнало в контрол панела на бозата и аре пускай на юзера да се мъчи.

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

мани, тия просто са си го изсмукали от пръстите...
как може в една функция да има 100 бъга. Първо пускат заявка без да знаят дали фифото не е пълно, то и чаршафа е леко подведжащ щото заявка се пуска с вдигане на едно битче когато канала е разрешен, а се флъшва с вдигане на същото битче при забранен канал. Та тия тия са си решили първо да вдигнат битчето без да мислят какво ще стане. После като проверяват кое фифо да гледат бъркат проверката за типа на ендпоинта. И не стига че ще гледат регистри от грешно фифо, ами във варианта с непериодично вземат и грешни битове на регъстъра. Изобщо бозата се лее отвсялъде...
Да не говорим на колко места имат фикснати регистри, а пък чеповете имат по 2 usb-та и се предполага че драйвера трябва уж да работи и с 2-та. То и тва да го нямаше на сума си места имат слийп по 200ms с while(); Aз не знам как ще работи устройството ако някой драйвер си позволява да блокира по 200ms.
Просто ужас, то не случайно повечето изобщо не се занимават с USB особено пък хост... Сега погледнах сорсовете дето имам на чиби-то, на нут-а.. няма, или моите копия са стари? Някой сеща ли се за host на STM32 освен тяхната боза?

Нута уж има HOST съпорт за STM. Или поне това пише в документацията.

верно бе!
мамка му, хем преди да почна проверявах и видях на главната им страница че споменават само LPC17xx като USB host и реших че няма смисъл да дърпам сорсове