Hice algo de desarrollo en una placa Nucleo-64 (específicamente NUCLEO-F303RE con el microcontrolador STM32F303RE) y usé OpenOCD y GDB con target remote :3333 para actualizar mi código (con load ) en mi microcontrolador.
Durante este tiempo, utilicé el puerto COM virtual del ST-LINK en mi máquina con Linux (Ubuntu 16.04 (Xenial Xerus)) para hablar con el USART del microcontrolador. Ahora me gustaría usar el puerto COM virtual para hablar con el microcontrolador sin necesidad de iniciar OpenOCD o GDB.
Me sorprendió descubrir que esto no solo funciona. Los síntomas son que mi dispositivo no recibe bytes enviados por el host ni viceversa. (Detecto que los bytes que llegan al dispositivo de destino parpadean un LED). Por lo tanto, parece que el estado del microcontrolador ST-LINK, o quizás el kernel de Linux en mi máquina host, se modifica de alguna manera por el proceso de conexión a través de OpenOCD y flasheando el programa.
Mi pregunta principal es: ¿es posible acceder a este estado de trabajo del puerto COM virtual en mi máquina Ubuntu 16.04 sin iniciar OpenOCD o GDB? Idealmente, no necesitaría usar ningún programa adicional, pero tal vez solo cambie alguna configuración.
Mi segunda pregunta es: ¿Por qué sucede esto? ¿El dispositivo ST-LINK está cambiando de modo aquí?
Y mi tercera pregunta: ¿Por qué sucede lo siguiente y qué puedo hacer al respecto? A veces, incluso después de un parpadeo exitoso, el microcontrolador de destino puede enviar bytes con éxito, pero no puede recibirlos. Además, creo que una de mis tarjetas no puede enviar ni recibir bytes con este método, aunque el firmware parece cargarse bien.
En MacOS 10.12.1, mi microcontrolador de destino se conecta inmediatamente y se puede acceder a él como se desee (sin que se ejecute ningún comando ni parpadee el firmware) a través del puerto COM virtual en, por ejemplo. %código%. Por lo tanto, ahora sospecho que el problema está relacionado con el lado del kernel de Linux y el controlador que crea /dev/tty.usbmodem1423 .