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

Thanks

#usb-device #stm32f4

[waclawek.jan]

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?

JW

[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

Dave

[waclawek.jan]

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.

JW