I did some development on a Nucleo-64 board (specifically the NUCLEO-F303RE with the STM32F303RE microcontroller) and used OpenOCD and GDB with target remote :3333 to flash my code (with load) onto my microcontroller.

During this time, I used the ST-LINK's virtual COM port on my Linux machine (Ubuntu 16.04 (Xenial Xerus)) to talk with the microcontroller's USART. Now I would like to just use the virtual COM port to talk the microcontroller without needing to start OpenOCD or GDB.

I was surprised to discover that this doesn't just work. The symptoms are that my device doesn't receive bytes send by the host nor vice-versa. (I detect bytes arriving at the target device by blinking an LED.) Therefore, it seems that the state of the ST-LINK microcontroller, or perhaps the Linux kernel on my host machine, is somehow changed by the process of connecting via OpenOCD and flashing the program.

My main question is: Is it possible to get to this virtual COM port working state on my Ubuntu 16.04 machine without launching OpenOCD or GDB? Ideally, I would not need to use any additional program, but perhaps just change some configuration setting.

My second question is: Why is this happening? Is the ST-LINK device itself changing modes here?

And my third question: Why is the following happening and what can I do about it? Sometimes, even after successful flashing, the target microcontroller can send bytes successfully, but is unable to receive them. Furthermore, I think one of my boards is neither able to send or receive bytes using this method although the firmware seems to upload just fine.

On MacOS 10.12.1, my target microcontroller is immediately connected and accessible as desired (with no further command running or firmware flashing) via the virtual COM port at, e.g. /dev/tty.usbmodem1423. Therefore, I now suspect the issue is with the Linux kernel side and the driver that creates /dev/ttyACM0.

  • \$\begingroup\$ You should just be able to install the driver and it behaves like a com port. \$\endgroup\$
    – Voltage Spike
    Feb 22, 2017 at 22:18
  • \$\begingroup\$ yes that board/family will work. some of the nucleos no some yes, the documentation tells you. no reason to use openocd nor gdb, these guys mount as virtual flash drives you simply copy the .bin file to the virtual flash drive to download/program the binary to the flash on the target mcu. the debug mcu along with providing stlink provides a usb virtual com port that connects to the RX/TX on the target MCU. For ubuntu no you dont need to install anything just minicom to /dev/ttyACM0 and copy your .bin file to the mounted virtual filesystem. \$\endgroup\$
    – old_timer
    Feb 23, 2017 at 2:46
  • \$\begingroup\$ Now saying that depending on the age of your board you might need to update the firmware on the debug mcu, the stlink of you will. there is a java based tool that works just fine on ubuntu/linux that you can update your board with. It helps with problems like can only write the .bin file some number of times then it says it is full, have to unplug and replug. the board. if you leave minicom connected to ACM0 when you do this even with the latest firmware it can sometimes get upset and not give you the right data at first I tend to close minicom before unplugging if it is necessary. \$\endgroup\$
    – old_timer
    Feb 23, 2017 at 2:48
  • \$\begingroup\$ As I tried to explain above, I am not having trouble flashing the board. My problem is communicating to the STM32F303RE using the virutal com port. \$\endgroup\$ Feb 23, 2017 at 7:30
  • 2
    \$\begingroup\$ It is possible that the modemmanager is grabbing the virtual serial port and attempting to send commands to find out what kind of modem it is. Receiving those unexpected commands might throw off your program's state when you do finally connect to it, making it appear as though the virtual serial port is malfunctioning. Using gdb/openocd to reset the microcontroller would then make those symptoms go away. If resetting the microcontroller manually fixes the problem, try adding a udev rule to prevent the modemmanager from grabbing the STLink's virtual serial port. \$\endgroup\$
    – Devan
    Feb 23, 2017 at 17:19

1 Answer 1


There should be no real interaction between GDB or OpenOCD and the virtual serial port of an STM32 Discovery or Nucleo board, however the modemmanager package installed by default in Ubuntu and derived distributions will substantially delay availability of the CDC/ACM device after each reset, which typically includes not just connections but some programming operations (at least those using the mass storage emulation).

Things will work much better with modemmanger uninstalled. Please don't argue about this until you have actually tried removing it - the issue is behind the scenes, a delay in the operating system making the port available to user programs. It makes the difference between the boards being essentially useless, and working fairly well (a udev rule or driver blacklist to ignore the marginally broken mass storage emulation is a good idea, too)

You will however still probably need to establish appropriate serial line settings, with something like stty if not an actual terminal program - without that (and possibly even afterwards) you can't just go using something like cat that is ignorant of serial port details to interact with the port (though often if you do have a terminal program running, you can use echo or cat and a shell redirect alongside to write specific lines to it)

  • \$\begingroup\$ Uninstalling modemmanager did indeed seem to make everything work. It's only lightly tested so far, but many thanks for convincing me to try this more thoroughly. \$\endgroup\$ Feb 26, 2017 at 16:31
  • \$\begingroup\$ So after more testing after uninstalling the modemmanager package, I am still having intermittent connection problems. Typically after a couple minutes of trying and retrying things start working. But overall I am quite frustrated that I still can't get reliable communication to my device over /dev/ttyACM0 with Ubuntu. \$\endgroup\$ Mar 1, 2017 at 19:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.