[Nucleo] Issues with Serial Port initialization after plugging in through built-in ST-link

[twjdeboer]

Hi all!

First time poster.

I'm working on a prototype that utilizes a Nucleo-G474RE to move some motors and read some sensors. The design is working great and my code is running as it should. However, recently I've been having some issues with the virtual COM-port on my Nucleo board. Whenever I program the device, it works perfectly.

When I unplug and replug the USB however, my serial connection doesn't respond in any way. This is true even when I plug in a completely fresh Nucleo directly to my PC, powered by 5V_STLK, no peripherals. The status LEDs on the device do function as expected, but no messages are received or transmitted.

Plugging in and then resetting the micro or removing and replacing JP6 fixes the issue, making the serial work again.

There has been a firmware update to the ST-Link 3 that's built in, and we made some minor changes to the code, but even rolling back to a known working version of our firmware does not help. I want to share our source, but it's for a customer, so I don't think I can.

Things I've tried:

1. Rolling back my firmware to a known version
2. Using a different board
3. Isolating the nucleo from the rest of the device
4. Putting a 1 second delay at the start of Main()
5. Removing the watchdog timer from my firmware

The issue exists in Windows as well Linux (in a VM), using terminal, putty and arduino IDE serial monitor.

I'm kind of starting to think the issue is with the ST-link firmware. I would love some help. My embedded engineer has given up and tells me to resort to manually resetting or reflashing the micro every time we need to use the machine, but that's unsatisfying to me.

Best wishes,

Thomas

[Andrew Neil]

---

@twjdeboer wrote:

When I unplug and replug the USB however, my serial connection doesn't respond in any way.

---

Please give more details on that:

• Does the port still appear on the PC?
• What are you using on the PC to interact with the VCP?
• If you probe on the UART lines, is there activity?
• Does the debug part of the ST-Link still work?
• If it does, have you used the debugger to see what's happening in this state?

---

@twjdeboer wrote:

Plugging in and then resetting the micro or removing and replacing JP6 fixes the issue, making the serial work again.

---

JP6 is the IDD link - so power-cycling the Target chip.

What JP5 settings are you using?

[twjdeboer]

• Yes, the port appears
• As stated I use Putty, but the issue persists from the Linux terminal and the Arduino IDE
• Have not tried, good suggestion!
• It seems like it does, but I don't have a lot of experience using it.
• Will try
• JP5 is on 5v_STLK when testing on my desk, but on E5V when in the device.

Thanks, I appreciate it!

[TDK]

Get the chip into the "bad" state, then attach a debugger and see where the code is at. Create a new debug configuration to do this which does not reset the chip or download the program.

[twjdeboer]

I'n not quite sure how to attach the debugger without also reflashing. If I uncheck 'download' from the startup tab in the debugger configuration, I cannot connect to the ST-link it seems. The console shows the following:

Starting server with the following options:

Persistent Mode : Disabled

Logging Level : 1

Listen Port Number : 61234

Status Refresh Delay : 15s

Verbose Mode : Disabled

SWD Debug : Enabled

InitWhile : Enabled

Waiting for debugger connection...

Debugger connected

Waiting for debugger connection...

Debugger connected

Waiting for debugger connection...

[twjdeboer]

We've switched the LPUART1 to UART1 and are checking with an external UART to USB interface. Everything is working as it should, indicating an issue with the initialization of the ST-LINK portion of the NUCLEO board.

[Andrew Neil]

Yes, setting 'Download' to false on the 'Startup' tab should do it.

You'd also want to disable the reset on connecting:

Does your code go into low-power mode, and/or reconfigure the SWD pins?

[Andrew Neil]

Well, you changed two things - so it could be either the ST-Link or something to do with LPUART1 ...

[twjdeboer]

We are using Free RTOS, but we're not using any of the low power modes in there. We're also not reconfiguring any of the SWD pins as far as I know.

[Andrew Neil]

Do you get the same issue without FreeRTOS ?