NUCLEO-F401RE ST-LINK/V2-1 not reliably sending data to USB host

[dlkeng]

Posted on May 25, 2014 at 05:48

On the NUCLEO-F401RE, using the STM32F4xx HAL UART driver function HAL_UART_Transmit() to send a sign-on message to the ST-LINK/V2-1 virtual COM port to the host PC, I have noticed the sometimes the full sign-on message of my application is not sent to the PC, just part of it is sent. The rest of the message will be sent the next time the any data (even just one character) is sent by the STM32F410RE.

I have written a simple application for the NUCLEO to periodically (every few seconds) send a fixed string of characters to the PC via the ST-LINK/V2-1 virtual COM port to better characterize the problem. The problem occurs fairly frequently but data is never lost, just delayed in the ST-LINK/V2-1. I have confirmed, using a logic analyzer on the MCU Tx pin, (CN3 Rx pin) that the data is correctly leaving the NUCLEO MCU and entering the ST-LINK MCU. However, it does not always all arrive on the PC's serial communications program. I have tried two different PC's: Windows XP SP2 and 64-bit Windows 7 with similar results with several terminal programs - Hyperterminal, ClearTerminal, PuTTY, Realterm, and Tera Term. I have also tried two different versions of the ST-LINK/V2-1 firmware: V2.J19.M3 and V2.J20.M4 with similar results. Also, the problem appears to happen more frequently at faster baud rates. I've seem the problem occur at 115200, 57600, and 38400 baud rates, but does not seem to occur at 19200 baud. When data is waiting in the ST-LINK/V2-1 (I assume that's whats happening as I do not have a way to monitor the USB bus to see for sure), sending data from the PC to the ST/LINK is correctly received, but does not cause the blocked transmit data to be sent (unless the received data is echoed, in which case any of the blocked data will be sent). Again, no data is getting lost, only sometimes delayed. This is unacceptable as I have applications that need the data to be sent reliably to the USB host when an event occurs at the NUCLEO board. #nucleo-f401re-st-link/v2-1

[S C]

Posted on May 27, 2014 at 17:12

Hello,

It will be interesting to confirm if the data are really delayed at ST-Link/V2-1 level or at higher level. Is it possible for you to share your binary file ? Any new data received from the target is expected to be committed to the USB at least on the next USB SOF event. Which can't explain the delay you noticed. Then the VCP driver on the host should see it in its next polling loop. This might add another delay (not so big I think also), but there might also be a cache flushing issue at this level. Only a trace at USB level can indicate where the bug resides. Thank you

[dlkeng]

Posted on May 27, 2014 at 18:33

Sorry, I don't have any way to trace the USB transactions.

Attached is the .hex file of the simple command line application firmware that can be used to demonstrate the problem. I run it on a Rev. C NUCLEO-F401RE. Every 2.5 seconds, it blinks the onboard LED and at 115200,8,n,1, sends the tick count from HAL_GetTick() followed by a string of ASCII characters similar to the following:

5000: 1234567890ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz

7500: 1234567890ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz 10000: 1234567890ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz 12500: 1234567890ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz Periodically (non-deterministic), a line of characters will only be partially received on the PC, even though they are sent by the STMF401 MCU to the ST-LINK/V2-1. Also, the user can on-demand send that character string by pushing the user button on the Nucleo. All received characters from the PC are echoed by this application, so if a partial line is received by the PC, sending any character from the PC will cause the rest of the character string and the echoed character to be received on the PC. BTW, the limited set of commands supported in this application can be seen by sending a '?' command followed by Enter. ________________ Attachments : F401RE_commandline.zip : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006Hz7V&d=%2Fa%2F0X0000000bMc%2FTGojFXKroNzQ5Po5dzyoHpN4TTUfo3rrBsfLtmYfM6I&asPdf=false

[S C]

Posted on May 27, 2014 at 19:41

OK thank you. I reproduced the issue in a similar context. Unfortunately the data are not delayed at ST-Link level, but at the host level. I catched an USB trace where all data were present in 5 consecutives USB frames sent in 6ms, while only the first 4 have been displayed by PuTTY in a first step. The last frame was displayed with the next line 2s later !

What is interesting to notice is that the 4th frame was a not-full USB buffer (because the line was not fully received on the USB event). However the remaining data are transmitted to the USB in the immediately following frame. But not displayed. I suppose the host driver or application might manage an incomplete USB frame as a signal that no data is expected in a short delay and this makes him sometimes miss the signal of the arising frame immediately after ? [not always, I also catched lots of USB traces with similar frame sequence but without any display issue]. In conclusion to these observations, I'm pretty sure this is not a bug at ST-Link level. And unfortunately I'm also afraid it will be difficult to implement a workaround at this level, because according to me the framing sequence at USB level is not inconsistent. I don't know if there is some application providing a ''refresh'' functionnality from the host side. If yes, this will be the solution for you because as you said, data are not lost, moreover I saw them transmitted at the right time over the USB, so I think it's ''only'' a signalling issue.