скрытое меню

Где эти ACK, NAK, STALL

ACK - нормальное выполнение команды хоста
NAK - девайс принял команду корректно , но еще не выполнил
STALL - (буксовать) девайсу что-то поплохело

CBW - Command Block Wrapper
CSW - Command Status Wrapper

Главное это сразу понять , что в коде , сгенерированном CubeMX явного вызова функций посылки ACK , NAK, .. вы НЕ найдете.

Эти пакеты формируются автоматически контроллером USB встроенным в STM32. В механизме прерываний и в коллбек функциях вы тоже не найдете эти команды посылки ACK , NAK, .. и т.д.

Также скорее всего вы НЕ увидите эти пакеты в программах типа USB анализаторов и это вас собъет с толку.

Наверное лучше эти пакеты воспринимать как состояние контроллера USB.

Т.е. если контроллер принял команду и долго ее выполняет , то он шлет на запрос (ну когда же ты девайс ответишь?) пакет NAK , означающий (я еще не подготовил данные). Это может продолжаться и секунду и дольше.

Cостояние NAK выставляется прямой записью в регистры USB определенных значений , примерно таким образом :

USBx_INEP(ep->num)->DIEPCTL |= (USB_OTG_DIEPCTL_CNAK | USB_OTG_DIEPCTL_EPENA);
То , что ниже в принципе можно не читать.

Universal Serial BusMass Storage ClassBulk-Only

Наконец-то находим даташит по протоколу и многое проясняется :

Command Block Wrapper

31 байтный стандартный пакет - так называемый Command Block Wrapper (CBW):

0-3: 55 53 42 43 - это dCBWSignature
4-7: E0 A9 2D EC - dCBWTag - The device shall echo the contents of this field back to the host
8-11: 24 00 00 00 = (24) - dCBWDataTransferLength - The number of bytes of data that the host expects to transfer on the Bulk-In or Bulk-Out endpoint
12: bmCBWFlags - 1 байт - Bit 7 =0 (Data-Out from host to the device 0x80) =1(Data-In from the device to the host)
13: - bCBWLUN - The device Logical Unit Number (LUN) to which the command block is being sent
14: bCBWCBLength - The valid length of the CBWCB in bytes
15-30: CBWCB - The command block to be executed by the device

фотка 1

Command Status Wrapper

Это 13 байтная короткая команда ответа :

фотка 2

0-3: 55 53 42 53 всегда сначала dCSWSignature
4-7: - dCBWTag - The device shall echo the contents of this field back to the host - Девайс указываем некие 4 байта , и смотрит , чтобы хост в следующей посылке их повторил.
8-11: dCSWDataResidue - (For Data-Out the device shall report in the dCSWDataResidue the difference between the amount of
data expected as stated in the dCBWDataTransferLength, and the actual amount of data processed by
the device. For Data-In the device shall report in the dCSWDataResidue the difference between the
amount of data expected as stated in the dCBWDataTransferLength and the actual amount of relevant
data sent by the device. The dCSWDataResidue shall not exceed the value sent in the
dCBWDataTransferLength)
можно указать оставшееся количество не переданных байт, т.е. запросили dCBWDataTransferLength , а мы минус сколько считали.
12: bCSWStatus 00 good status, 01 Command Failed, 02 Phase Error

Тут в ответе хосту состояние занято в принципе как передать?

BCSWStatus либо good status либо Failed и это явно не для этого.

Если вы захотите использовать поле dCSWDataResidue как сигнал , что данные еще не готовы , то у вас ничего не получится. Для этого используется только NAK пакет.

Этот кусок не показывает истинного протокола обмена.

Вот маленький кусочек обмена по USB , снятого USBLyzer-ом. Когда инициализации прошла , ПК узнал , что перед ним флэшка и что ПК делает дальше .

Тут между показанными пакетами, еще очень много NAK, ACK пакетов.

фотка 3

Вот маленький кусок огромного лога анализатора LA1010

Тут как раз показан один из многократно повторяющихся пакетов NAK :

фотка 4

Ну и для еще большего понимания выгруженный протокол обмена в файл:

фотка 5