Virtual COM port in STLink doesn't work while debugger attached

[DmitryK]

Hi.

NUCLEO-F303RE has STLink onboard with integrated Virtual COM port, which seems very nice solution. Sadly Virtual COM (UART2) doesn't seem to work properly while debugging session is active. I made simple app, which just prints simple string to UART2 and entering endless loop. It works fine when flashed to MCU and reset pressed. I can see my "welcome prompt" string in terminal (connected to /dev/ttyACM0). But if I start debug session with openOCD ("serial wire" debug option) it outputs some garbage to terminal instead of "welcome prompt". Debugging itself works fine. After stopping openocd session and resetting, Virtual COM port works fine again.

Tried to minimize baud rate to 9600bps - it doesn't helps.

So, is this a known limitation of STLink with integrated Virtual COM port? Am I doing something wong here? Is there any workaround?

Of course I can use separate USB-UART converter and pretty sure it's going to work, but I'd prefer to minimize number of devices and wires if possible.

[TDK]

I've used the VCP interface while debugging on a large number of STM32F4 and STM32H7 boards and it's always worked great. Both ST-Link V2, ST-Link V2/1 and ST-Link V3. This is with OpenOCD. Just a data point.

[Bob S]

Could it be that your debugging session startup script sets/changes some clock setting that your code doesn't touch and this messes the UART baud rate? If you have a scope, look at the UART2 TX line in both cases and see if the bit rate is what you expect. Like @TDK​ I've used the VCP on the STLink with no issues on many different boards, though granted not with an F3xx CPU.

[Tesla DeLorean]

>>So, is this a known limitation of STLink with integrated Virtual COM port? 

Works fine in Windows with Keil, so assuming it's your OS or drivers, and perhaps some semaphore, mutex or ownership of resources there.

[Panometric]

I've seen something similar, but on a different MCU. A few things to try:

1. What is the source of your UART clock? Try a completely different clock source.
2. openOCD takes longer to connect, and the device actually runs a partial second before the debugger traps. Try using GDB, it's faster.

[DmitryK]

Today investigated the issue more. Found out culprit and workarounds. The cuprit seems to be an openOCD. I'm not sure if this is the cause, but there are some warnings at startup about clock:

/opt/stm32/openocd/bin/openocd -c "tcl_port disabled" -s /opt/stm32/openocd/share/openocd/scripts -c "gdb_port 3333" -c "telnet_port 4444" -f board/st_nucleo_f3.cfg -c "program \"/home/kotnia/projects/rotenc_stm32/cmake-build-debug-stm32_gcc8/rotenc_stm32.elf\"" -c "init;reset init;"
Open On-Chip Debugger 0.10.0+dev-00925-g0819541 (2019-08-31-22:04)
 
Info : clock speed 1000 kHz
Info : STLINK V2J36M26 (API v2) VID:PID 0483:374B
Info : Target voltage: 3.257255
Info : stm32f3x.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : Listening on port 3333 for gdb connections
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : Unable to match requested speed 1000 kHz, using 950 kHz
 
Info : Unable to match requested speed 8000 kHz, using 4000 kHz
Info : Unable to match requested speed 8000 kHz, using 4000 kHz

What is interesting is VCP starts to work correctly after second reset. So first workaround would be:

• Start openOCD debugging session
• notice VCP transmits garbage
• press reset (hard or soft - doesn't matter)
• VCP starts to work properly (debugger still attached and works fine too)

While being acceptable it's not very convenient. So I decided better solution would be to use ST-gdbserver, which may be found in stm32CubeIDE package (thanks to @Panometric​ for the advice). ST-gdbserver works just fine and quite convenient to use with my IDE.

Thanks everyone who tried to help!

p.s.

I was too lazy to experiment with UART clock. Sorry.

[Piranha]

I also have virtual COM port of ST-LINK V2-1 on STM32F769I-DISCO and NUCLEO-F767ZI working simultaneously with the debugger up to at least 921'600 bps without problems. Also I've done that with both firmwares - the original one and J-Link OB conversion.

It could still be your UART and/or other code on MCU...

[samuel23]

I have the same issue.... I think it is related with some recent changes in st-link firmware.

Indeed, I use the Nucleo F103 with VCP in many contexts since years (and "student-proof" contexts!... which is.... instructive ^^).

Recently, the VCP is sometimes impossible to open...

Some serial-terminal-software indicates the port is still in use.

I investigated and found this:

• While debuging session is active, if my software does not send anything to the UART, I can open the VCP (always..)
• While debuging session is active, If my software send some datas to the UART before opening the VCP, it is sometimes impossible to open the VCP next (until reset the ST-Link MCU)!
• If i do not kill the debugging session, unplug+replug USB -> I cannot open VCP.
• If i kill debugging session, unplug+replug USB -> that is OK!

So the problem seems appear when datas are send to the "ST-link-f103" during openocd is running on the host.

My context: OpenWorkbenchForSTM32 (using OpenOCD+GDB) + external serial terminal.

I guess this problem is appears recently in the ST-Link firmware.

Sorry... my "answer" is not relly an answer... but it could help to focus (/correct?) this f**ing problem!

[toniospritz]

i've hae had a similar problem, but with simulink in PiL mode. try to disconnect the sw4stm32, or in general eclipse, before you start to flash the program.on the stm. Only after, open your preferite terminal.

[machinehum]

I've had the same issues - any solution?

• Open On-Chip Debugger 0.10.0+dev-01514-ga8edbd020-dirty
• GNU gdb (GDB) 10.1
• Blue pill dev board
• ST link V3