Showing results for 
Search instead for 
Did you mean: 

IN endpoints payload corruption with USB HAL device library

Dave Glenton
Posted on October 05, 2017 at 16:53

My application configures the STM32F4 USB OTG HS block as a FS device with 3 non-zero IN endpoints (1,2 & 5)

In normal operation 44 byte payloads are sent to EP5 and 27 byte payload to EP1 ~ every 10ms.

All works fine for a period (2 to 120 seconds) but eventually I see a 1041 byte packet come out of one of the endpoint.

If the problem occurs on EP1 (expected 27 bytes) the first 20 bytes (0:19) are correct then the next 8 bytes (20:27) are the first 8 bytes of the next EP5 payload followed by either lots of 0x00 or a 4-byte pattern repeated.

If the problem occurs on the EP5 (expected 44 bytes) the first 36 bytes (0:35) are correct then the next 8 bytes (36:43) are the first 8 bytes of the EP1 data followed by lots of 0x00

It is worth noting that Tx FIFO access is performed a 4-byte writes

Using some spare pins and a 4 channel scope and have checked that the  Tx FIFO is being written to the expected number of times in USB_WritePacket().

I also have put some some debug into USB_EPStartXfer() to catch any unexpected packet/transfer values being writem to the DIEPTSIZx regs 

Anybody got any other ideas


#usb-device #stm32f4
Posted on October 06, 2017 at 15:57

Can't this result from FIFO overflow? What's the configured bInterval (I presume they are of Interrupt type)? What is the content of all FIFO-governing registers (GRXFSIZ, DIEPTXF0, DIEPTXFx for all endpoints not just those two)? Upon which stimulus do you write data? Can you add a FIFO-empty-enough check into USB_WritePacket() based on reading respective DTXFSTSx?

Do you use DMA in the OTG_HS?

Btw. don't you run some form of multitasking which could mess up things on the programs level?


Dave Glenton
Posted on October 09, 2017 at 12:49

Thanks for the pointer Jan, in looking at how I had the FIFO configured I found the assigned FIFO address offset for EP1 and EP5 where overlapping! 

Further investigation found that I was requesting way too many 32-bit words for each of the Tx  FIFOs with HAL_PCDEx_SetTxFiFo().

This code dates back to the very beginning of our project and I suspect  the values requested were a combination of copy-paste-and-forget-to-modify and missing the fact that the size request is in 32-bit words NOT byte.

Anyway my original problem can be turned on and off by switching between sensible and excessive values.

Thanks for your help


Posted on October 09, 2017 at 12:52

my original problem can be turned on and off

What an apt description of what is the essence of debugging.

Thanks for reporting back with the result.