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