Is it possible to get ST-LINK's virtual COM port working without launching any program in Ubuntu?

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.

• You should just be able to install the driver and it behaves like a com port. – Voltage Spike Feb 22 '17 at 22:18
• 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. – old_timer Feb 23 '17 at 2:46
• 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. – old_timer Feb 23 '17 at 2:48
• 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. – Andrew Straw Feb 23 '17 at 7:30
• 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. – Devan Feb 23 '17 at 17:19

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)