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.
Best Answer
There should be no real interaction between GDB or OpenOCD and the virtual serial port of an STM32 Discovery or Nucleo board, however the
modemmanagerpackage 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
modemmangeruninstalled. 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
sttyif not an actual terminal program - without that (and possibly even afterwards) you can't just go using something likecatthat is ignorant of serial port details to interact with the port (though often if you do have a terminal program running, you can useechoorcatand a shell redirect alongside to write specific lines to it)