cancel
Showing results for 
Search instead for 
Did you mean: 

NUCLEO-L152RE - Sending data at 115200 baud on USART2 kills ST-LINK VCP

sean
Associate
Posted on May 17, 2014 at 23:48

I trying to send continuous serial data at 115200 baud using USART2 which is connected to the ST-LINK portion of the NUCLEO board.  ST-LINK implements a VCP which I'm accessing via a terminal on my PC.  If I space the characters out (e.g. send 1 every 100 ms) everything works as expected - terminal on PC is updated with the characters as they are received.  If I send batches of characters (e.g. send 5 every 100ms), again everything works as expected.  However, if I send continuous characters then the VCP stops working (I receive nothing on the terminal), even though I can see the data being sent on the RX pin of CN3 on the NUCLEO board using an oscilloscope.   Additionally the ST-LINK commands from the PC no longer work (I can't debug or load code), nor does the USB drive emulation work.  It seems that U2 (STM32F103CBT6) that implements the ST-LINK, USB Drive and VCP ''crashes'' when receiving continuous data at 115200 baud on PA3/STLINK_TX.

Has anyone else experience this?

Is this a known limitation, and if so what is the maximum continuous character rate that the ST-LINK VCP can handle?

Are there any known work arounds?

Would it be possible to get updated ST-LINK firmware for the NUCLEO board that addresses this issue?

As a side note, once code has been loaded that sends continuously at 115200 baud you can no longer load code on to the NUCLEO board unless you remove SB13, then load code, then reinstall SB13.

#nucleo #stm32 #usart
6 REPLIES 6
Posted on May 18, 2014 at 17:52

I've had Nucleo boards sending via the virtual serial, but did not try saturating the connection.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
S C
ST Employee
Posted on May 19, 2014 at 17:37

Hello,

may you please firstly check if the firmware is up to date (V2J20M4) by running STLink-Upgrade.exe available at

http://www.st.com/web/en/catalog/tools/PF260217

.

There is a fix in this version that can explain the issue if you are not up to date (see also the release notes).

Best regards
sean
Associate
Posted on May 19, 2014 at 22:36

Thanks for your replies.

I am running firmware V2J20M4.

I've done a few more experiments:

  • I can send continuously at 9600 baud without ''crashing''.
  • I can send at 115200 baud if I space the characters out so they arrive 1 every 1ms (measured from falling edges of the start bits - 1000 characters/s) without ''crashing''.
  • I can send bursts of 13 characters every 100ms at 115200 baud without ''crashing''.
  • If I send bursts of 14 characters every 100ms at 115200 baud the STLINK ''crashes'' (VCP , USB Drive, and STLINK Debug stop working).

Any other suggestions?

Is this the right forum to engage the maintainers of STLINK firmware?

Posted on May 20, 2014 at 00:03

Is this the right forum to engage the maintainers of STLINK firmware?

In my experience probably not, this is a user forum.
Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
S C
ST Employee
Posted on May 20, 2014 at 17:05

Hello,

is it possible to share your .bin file making crash ? Saturation tests at this baudrate did not show such behaviour so far, most probably there is a difference in the context of both situations.

Thank you

Posted on May 20, 2014 at 17:57

Saturation tests at this baud rate did not show such behaviour so far

Seems to work here too (Win7 x64, V2J20S4), 115200 8N1 saturation code in Keil, debugs and permits access, also functions under ST-LINK Utilities.

________________

Attachments :

USART2NUCLEO-L152RE-SATURATE.hex : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006HzuL&d=%2Fa%2F0X0000000bRJ%2FgSCdl903enAYnsH0EUMLQ8hOjkutaBRn.gnpKe70ckE&asPdf=false
Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..