cancel
Showing results for 
Search instead for 
Did you mean: 

Virtual COM port: LPUART or USART on Nucleo-144 board (MB1361)

Zaher
Senior II

Hello,

I was wondering if anyone has used the STM32 Virtual COM Port (VCP) on the Nucleo-144 board (MB1361) with USART or LPUART for printf debugging. As far as I can understand, PG7 and PG8 are connected to VCP through ST-Link. In this case, the output has to be re-directed to LPUART1. But what about VCP on the user's USB device port? Can I still use that for the same purpose apart from ST-Link VCP?

Thx,

Zaher

1 ACCEPTED SOLUTION

Accepted Solutions
Zaher
Senior II

I can confirm now the code works flawlessly and I can debug/retarget printf output to terminal over ST-Link connection. No extra USART is required, no jumper cables, and most important from all, it's all through VCP over ST-Link connection. Previous build had an illegal access to memory. I solved it and now everything is working normally.

0693W00000LyFreQAF.jpg

View solution in original post

3 REPLIES 3
KnarfB
Principal III

Yes, you can implement a VCP on the user's USB device port, but this requires the USB-stack in your firmware and therefore is not as robust if case of bugs in your firmware like overwriting memory, or interrupt/timing sensitive issues. So you might be better off by off-loading this to the separate ST-LINK chip.

You can redirect printf to any peripheral, even multiple ones, simply overload _write or __io_putchar in syscalls.c (for gcc)

hth

KnarfB

Zaher
Senior II

Well, from the manual of the MB1361 board (Here) it looks like the VCP to LPUART1 connection is possible by default because jumpers SB127 and SB129 are ON. Not sure about the others. I have added the USB stack/Communication Class Device to the firmware, but as far as I recall, last time I built the code with LPUART1 enabled and printf redirected to LPUART1, I had a hard fault.

From the firmware perspective, I would absolutely prefer to off-load USB related interrupts to the ST-Link because my firmware has a lot of time sensitive routines. You're right. I could have redirected printf to any USART peripheral, but I want to make it very easy for end-customer to interact with board without the need for serial-to-usb TTL adapter. That's why I thought taking serial output/debug off the user's USB side is the easiest approach. I do not plan to use LCD/GUI for this project.

Another option that appeals to me is to implement the HID Class. I wanted to do it on many projects I've done, but I have no idea where to start with the Windows application development and the tools required to do it.

Thanks,

Zaher

Zaher
Senior II

I can confirm now the code works flawlessly and I can debug/retarget printf output to terminal over ST-Link connection. No extra USART is required, no jumper cables, and most important from all, it's all through VCP over ST-Link connection. Previous build had an illegal access to memory. I solved it and now everything is working normally.

0693W00000LyFreQAF.jpg