STM32F769 USB Device High Speed

[barryccl]

I am using FW_F7_V1.17.2 on STM32Cube to configure USB HS Device as a CDC. We are running with FreeRTOS and FatFS on a custom PCB.  The external Phy is a USB3300.  I am using MDK 5 IDE.

The STM32 is connected to a Windows 10 host, using a simple protocol to transfer data.  When receiving, the host sends blocks of ~1kB of data and the STM32 responds using a short reply packet of 3-4 characters.  This works well initially, with good data throughput for maybe 180 blocks or so.  The system then stalls because the Windows side is not getting replies.

The reason for this is that CDC_Transmit_HS() returns USBD_BUSY continuously, because the flag TxState is non zero.  Once in this state we are stuck.  USB data can still be received, but we cannot transmit.  There appears to be a bug in the ST USB Device stack, because this flag is not cleared by disconnecting USB, which I would have expected to reset the stack.

Now TxState is cleared in USBD_CDC_DataIn() and my debugging shows this is never called when the stall happens.

I am not familiar with the USB Device stack.  I would appreciate any suggestions on how to debug this problem, or any thoughts about what may be happening.

[FBL]

Hi @barryccl 

Are you enabling "Internal USB DMA"? If you get some transfers, then it stalls, the issue may be linked to non-word aligned addresses.

[barryccl]

Hi @FBL 

I don't see DMA as an option in CubeMx - I guess it is mandatory for HS USB, but I believe I have word aligned buffers as I have replaced the auto-generated defs with:

uint8_t __attribute__((aligned(4))) UserRxBufferHS[APP_RX_DATA_SIZE];
uint8_t __attribute__((aligned(4))) UserTxBufferHS[APP_TX_DATA_SIZE];

(I am using the ARM compiler.)

I have tried a couple of things.  The first is to increase the interrupt priority for the global UAS HS interrupt, and the second was to increase stack sizes.  Neither change had any effect.

It appears it is only one end point that is stalling, so I wonder where is a good starting point to debug that?

[FBL]

Hi @barryccl 

Indeed, it is optional in STM32F769.

Do you have a trace of USB traffic? Are you sure at least which EP is stalled (Control, BULK, Interrupt)? For example, EP0 must never be stalled. 

[barryccl]

Sorry I missed the DMA option - it is enabled.

I have attached a log of the USB packets.  This is an extract - you can see that the Windows app is sending packets of about 1kb on endpoint 1.  After each block is sent, the app waits for the 5 byte response before sending the next block.

I have marked the start of the problem with a line of asterisks - the reply from the device is zero bytes rather than the usual 5, and the status is 11.  Then there are a load of Reset Pipe's happening.  I do not believe that the app is doing this.

I appreciate your help with this!

Barry.

[barryccl · Accepted solution]

In case anyone else has this problem, I think I found a fix

The option 'Enable Internal IP DMA' must be disabled.  The problem is not to do with buffer alignment as I checked this, it seems to be a timing issue and may be specific to the use of FreeRTOS.

Note that the option 'Use dedicated end point 1 interrupt' must also be disabled as that also prevents USB comms.