STLink-V2 VCP @ 115,200

[jcsoo]

Posted on July 10, 2017 at 23:40

I'm running into an issue with the STLink-V2 VCP when transmitting TO the dev board at 115,200. It is suspiciously similar to this old post, except in the opposite direction: 

https://community.st.com/0D50X00009Xkh6hSAB

 

Sending single characters with approx. 50ms delay between characters works, when using a 40ms delay, the device stops receiving characters. The test code on the device (nucleo-l031k6 and also the nucleo-f303ze) is a simple busy loop that receives a character and then toggles the LED, with nothing else running and no interrupts enabled. 

The firmware version is V2J28M18, and this is occurring with macOS Sierra 10.12.5 and with Ubuntu 16.04 running in VMWare Fusion. All other STLink functionality seems to be fine.

Unfortunately I don't have a code sample (I am implementing low-level libraries for a compiled non-C/C++ language and don't have a C toolchain set up at the moment) but the UART TX side is solid and the only thing that the RX side is doing is polling on RXNE, reading RDR and toggling the LED.

When sending larger packets of data, I can get the transmit side of the VCP to hang up completely so that a full USB disconnection is needed for even individual characters to make it through - a simple reset of the device doesn't fix things.

My suspicion is that the VCP firmware was implemented with only interactive terminal use in mind, and perhaps only uses a single buffer that is sufficient for that purpose but not for more intensive use.

Has anyone here successfully used the STLink-V2 VCP to transmit bulk data to a connected device? I'm really trying to avoid having to use an external serial connection - I may have a dozen or more Nucleo boards connected at a time, and having to manage a dozen additional USB serial adapters would be a huge pain.

null

[Tesla DeLorean]

Posted on July 11, 2017 at 03:01

Pretty sure I've run X-MODEM transfers over the VCP in the past, and I've definitely done firmware updates ~512KB forwarding the VCP USART to a secondary USART with a GPS receiver attached.

[jcsoo]

Posted on July 11, 2017 at 15:43

Thanks very much for the response. Do you happen to remember what baud rate this might have been at?

After some more testing, I took out a delay before the beginning of the main loop which may been causing the single-character delay issue from my original post. However I am still running into some problems which prompted the original investigation.

Some test cases:

1 character writes with 1 ms between each write: works fine indefinitely

4 character writes with 1 ms between each write: works fine indefinitely

7 character writes with 1 ms between each write: works fine indefinitely

8 character writes with 1 ms between each write: fails to transmit after first write, but continues to accept characters until hanging without triggering timeout after about 200-400 characters (varying)

1 character writes with 0 ms between each write: stops transmitting after a handful of characters,

but continues to accept characters until hanging without triggering timeout after about 200-400 characters (varying)

I have also run into cases (not reproduced here) where the hang cannot be interrupted without disconnecting the USB device. I have also seen a few cases where transmitting bursts of characters appears to generate junk characters in the receive stream.

The same code running against a DAPLINK VCP doesn't have any of these issues - you can get a timeout if you send characters faster than the UART can handle, which is fine.

This makes me suspect one or more buffers are being overflowed - a short ~8 byte per-transaction USB buffer and a longer ~256 byte UART tx buffer.

Anyone with USB CDC experience want to comment?

[Tesla DeLorean]

Posted on July 11, 2017 at 18:32

Ran some tests this morning after porting code to an STM32L072CZ based board, X-MODEM-1K at 9600, 115200 and 460800 baud, 395KB file, transferring PC to DISCO.

ST-LINK V2-1

V2J27M15

V2J28M18 updated to this and repeated 460800 baud test

Did a test at 921600 baud which also worked, not sure where the ceiling is, but that seemed high enough. It might get to 2 Mbaud but that probably has an impractical interrupt loading.

[jcsoo]

Posted on July 11, 2017 at 20:39

Thanks very much, that's very helpful. I reran my latest tests with Linux, and it seems to work fine there. I suspect there is a difference in how the current macOS USB CDC driver accesses the VCP.

Restricting writes to 7 byte chunks isn't ideal, but it works for now.

[Torsten Jaekel]

Posted on September 14, 2017 at 22:34

I have similar trouble to use ST-LINK VCP on a STM32F4 DISCO1 board (supporting mbed and providing VCP UART on ST-Link USB connector):

It does not seem to support flow control. Due to fact that VCP is USB Bulk transfer, and potentially just every 1 ms an USB packet is transmitted (not sure what is the packet size, 2 bytes or up to 64 bytes - it does not look like). It works fine as long you enter interactively (a slow typing user on UART terminal). But if you send a file, e.g. in TeraTerm Send File ... or you write a Python script which sends UART characters - the maximum the DISCO1 can receive are two characters. Fast UART traffic results in losing characters, overrunning the ST-LINK VCP UART.The only solution is to add a 1 ms (or larger) delay after EACH characters. But this slows down the UART speed so much (looks like a typewriter now).

A) is there a way to use ST-LINK VCP UART with a XON/XOFF flow control? (HW flow control is not supported, not wired on UART1)?

B) I want to use baudrate 1,228,800 - which works fine, except that sending files, very seamless UART traffic (e.g. from a Python script) does not work.C) what is the maximum packet size on USB bulk transfer? (it looks to me: 2 bytes from PC to DISCO1 and assuming 64 bytes from DISCO1 to PC - I had to make sure in the same way, when sending large log messages from board - that I split into USB packet chunks, with a 1 ms delay in between, otherwise also lost characters).

Please, STM team - could you provide a ST-LINK VCP version which supports flow control (XON/XOFD) and/or larger USB packets in both directions (assuming in FS USB mode: 64 bytes is max. for End Point)?

==> How to use the ST-LINK VCP (which is actually really great feature) for large messages, sending files, use UART in scripts ...?

[Tesla DeLorean]

Posted on September 14, 2017 at 23:45

>>A) is there a way to use ST-LINK VCP UART with a XON/XOFF flow control? (HW flow control is not supported, not wired on UART1)?

Pretty sure X-MODEM embodies that type of software flow control and pacing...

[Torsten Jaekel]

Posted on September 15, 2017 at 16:46

Thank you.

Just: what does it mean?A) ST-LINK VCP (in the debugger STM MCU) does support X-MODEM protocol? (I do not guess)B) user had to implement X-MODEM protocol in the target MCU, e.g. on UART1? (my assumption, as to do for MCU FW)Actually, it will not help for my use case:I want to send UART messages from Python scripts, e.g. all the terminal commands which I could enter in TeraTerm or any terminal are generated by a script. Script uses just pyserial and regular UART driver, not any X-MODEM layer. And here we do not have any flow control, the script would send UART characters, strings etc. way to fast and w/o 'back pressure'.

When there is a statement, that Flow Control should work with 921,600 baud rate, why not with 1,228,800? (it is OK for user entered terminal characters) I would still think: flow control is not supported in ST-LINK VCP. But adding X-MODEM protocol in the target MCU (ST-LINK forwards USB UART to regular UART1 on target MCU) and X-MODEM protocol in MCU FW is based on packets, chunks with acknowledge - OK.

Just curios: my impression is: the USB bulk transfer sends just 2 characters (bytes) in one USB packet (max.) so that X-MODEM had to acknowledge after every two bytes? (which is also quite slow at the end).

[Tesla DeLorean]

Posted on September 15, 2017 at 17:08

The VCP implementation is agnostic to the protocol, it passes data correctly and accurately.

For Python we've used a USART with hardware flow control, the ST-LINK/VCP is a TX/RX only implementation. I don't think there is a strong desire to soak up more pins. If python can't inherently sink data quick enough then it needs to implement some flow control, or protocol that achieves it. Long history of async file transfer suggests you can't just stuff it on the wire.

Haven't tried 1228800, not a standard baud rate here, and has issues with MAX232 type devices which filter >1Mbps.

Here X-MODEM-1K sends packets a little larger than 1K with headers, and CRC included, no idea how the USB transfer decomposes these, but the PC app sends them en mass, and the host app receives them all, with speeds that scale proportionally, ie no 1ms byte delay nonsense, as fast as I can send it. Single byte per packet acknowledge.

If you write data to FLASH you're going to have problems, because that IS slow, and stalls the processor beyond the real-time requirements of the USART