Putting two 32-bit words in TxFIFO. How to guarantee USB controller doesn't send only half my data?

[Parawizard]

If my data is more than one 32-bit word and I have to write it one 32-bit word at a time to the FIFO, is it possible that the USB controller could send just the first 32-bit word? Is there a way to stop that from happening?

Thanks

```
USBx_DFIFO(1) = send.u32[0];
// Is it possible for the USB controller to send just the first 32bit word if timing is right?
USBx_DFIFO(1) = send.u32[1];

```

[Parawizard]

Context:

HID device
Interrupt Transfer
6 byte report

[gbm · Accepted solution]

The USB device controller will always send the programmed number of bytes. There are two very different kinds of USB periperal in various STM32. With the simpler one, you prepare data first, then trigger the transmission. With OTG, you first setup the transfer then load data to FIFO, but the transfer doesn't start until the full packet data is loaded. So no, USB device will not start sending anything until you write the declared amount of data.

[Parawizard]

Thank you for the awesome reply. This makes sense.

Cheers

[Parawizard]

Wanted to follow up on this. Actually found that if I am writing two 32 bit words to the FIFO and there is an interrupt between I get corrupted data sent on with my IN report! Seems likely the same errata is present in OTG_HS for STM32F723: https://discord.com/channels/577845172973469708/886209218263277569/1331525462299639838

OTG_FS 2.27.1 Transmit data FIFO is corrupted when a write sequence to the FIFO is interrupted with accesses to certain OTG_FS registers Description When the USB on-the-go full-speed peripheral is in Device mode, interrupting transmit FIFO write sequence with read or write accesses to OTG_FS endpoint-specific registers (those ending in 0 or x) leads to corruption of the next data written to the transmit FIFO. Workaround Ensure that the transmit FIFO write sequence is not interrupted with accesses to the OTG_FS registers

I am sending 6 bytes and I am losing 1 byte off the end. The CRC is also wrong so the host throws it away. It is similar to the findings here as well: https://community.st.com/t5/stm32-mcus-embedded-software/synopsys-otg-fifo-clash/m-p/359501

---

[gbm]

That's one more reason for calling the USB routines only from the ISR of the same priority as USB hw interrupt - something I advocated for for ages.