NUCLEO-F103RB USB Virtual COM Port Ceases to Function after 2-4 minutes

[jcrollman]

Posted on July 02, 2015 at 16:07

I have my Nucleo-F103RB virtual serial port over USB working for a short period of time. Usually around 2-4 minutes it will continue to push data across to my terminal. Then serial data will stop. USB is still functions, I can program the Nucleo just fine after serial data stalls. I see data being sent by the application micro (via serial) to the STLINK micro. No error is reported by windows device manager, the COM port is still functioning as far as Windows 7 (64-bit) is concerned. But serial data coming into the STLINK to the from the application micro never makes its way through to the USB. Reprogramming the micro or resetting the micro doesn't fix it. The only way to make it work again is by unplugging the nucleo from the computer.

I installed the STLINK009 is installed in windows. If I were a betting man, I'd say there is something wrong with the STLINK firmware, possibly sketchy support of USB 3.0.  I've tried a couple of older computers, and they all function correctly.

I've changed the baud rate, the data being sent, the com port number. I've tried multiple USB ports. I've tried every STLINK firmware available. Same result.

Anyone familiar with this issue?  I am working on a Dell Precision M3800.

[nesrine]

Posted on July 03, 2015 at 14:34

Hello,

- which is your ST-Link firmware version ?- check that it is up-to-date (V2J24M11), using ST-LinkUpgrade application If not, update it and see if it solves the issue Syrine.

[jcrollman]

Posted on July 06, 2015 at 18:20

I do have the latest firmware - I've also tried rolling back the firmware to see if that would help, which it didn't.

[jcrollman]

Posted on July 06, 2015 at 18:29

I have resorted to switching to an old 32-bit Windows 7 computer (as opposed to my main 64-bit machine), and the Virtual COM Port works like a champ.

This is not ideal, however. I'd rather not sit with 2 open laptops on my desk. If there is any other information people may have about this problem, please let me know.

[S C]

Posted on July 07, 2015 at 10:47

Hello,

which is the terminal application on host side ? Did you try putty for instance ? What happens if you restart the terminal application on host side without restarting the ST-Link ? Is it possible to check, after the issue, if a data sent from the terminal is seen on Tx pin of ST-Link ? We are not aware of such issue with recent firmware version (V2J24M11), despite also having PCs under Windows7-64bits, but we will stress that. Best regards

[jcrollman]

Posted on July 08, 2015 at 16:20

I tried three different terminals, including Putty. They all act the same way.  I normally use Br@y's Terminal.  After the communication ceases, if the Br@y's terminal is restarted, the problem is unchanged.

Before lockup, if you try to send data to the STLINK through the terminal, the transmission is reflected on the STLINK_TX pin. After communication ceases, if you try to send data to the STLINK through the terminal, it is not reflected on the STLINK_TX pin.  In fact, the terminal application seems to stall, and I can see a lot USB traffic (presumably because the STLINK isn't responding to the hosts commands, and the host is freaking out).  After a few minutes, USB communication stops.  This is repeatable.

[S C]

Posted on July 09, 2015 at 10:09

Hello,

Thank you for all details. I'm suspecting the USB communication rather than the ST-Link UART. But still did not hit any failure after more than 1 hour with an application sending data at 115000 bauds (and I also run simultaneously an STMStudio session for stressing the USB). There is an external condition impacting ... Perhaps the application (data rate, alignment ...) => is it possible to post the binary here ? Or the host USB driver => we will try on different machines. Thank you

[jcrollman]

Posted on July 09, 2015 at 22:21

I've taken some pictures of my computer attributes if they help. I've also attached the binary of what I am running from an application standpoint (it is very basic).

________________ Attachments : 2015-07-09_09_10_28-System_Information.png : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006Hzy2&d=%2Fa%2F0X0000000bRY%2FFpqLRnZQDtnOzAUtLzBSMnALXASfHnxXEu1cl1RFpcU&asPdf=false2015-07-09_09_11_41-System_Information.png : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006Hzuu&d=%2Fa%2F0X0000000bRX%2FQtxWC_VFSFB4dUYP5OOkE_awZ7T2ZlbknBAKfX_YB3U&asPdf=false2015-07-09_09_17_27-Computer_Management.png : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006Hzxi&d=%2Fa%2F0X0000000bRW%2Fi60yhjnw7bWGPrF7CoLLCTGmkKSb6zTMJQdPJXTKyFM&asPdf=false2015-07-09_15_20_39-mbed_Compiler__Nucleo_PC_CommUART_main.cpp.png : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006Hzm7&d=%2Fa%2F0X0000000bRV%2FfzoxjQx8UktXQNcLSnNoO6QiWHmIgwtlq5vr2xghxek&asPdf=falseNucleo_PC_CommUART_NUCLEO_F103RB.bin : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006Hzqs&d=%2Fa%2F0X0000000bRU%2FwqkEGWJa9BD5m0RNUTBHv.3UbhiRg4x9_6fOLgnCIIc&asPdf=false

[Tesla DeLorean]

Posted on July 09, 2015 at 22:54

Not sure I have an F103RB Nucleo, but I've run others (F401RE, L152RE) for extended periods piping data out the serial port. Admittedly not via mbed. Most of my entire fleet of systems are running Win7 x64 on multiprocessor systems.

[Tesla DeLorean]

Posted on July 09, 2015 at 23:16

I'll leave an NUCLEO-F401RE running equivalent code built in Keil running on an AMD Phenom X6 (Win7 x64 Hex-Core) overnight. Run 500 seconds so far.

If I can find a Nucleo-F1 in the junk box, I might try to toast that with a DELL Dual Quad Xeon. USB3.0 might be more difficult, only have that on an AMD machine, so probably not got a similar enough driver stack to matter.