cancel
Showing results for 
Search instead for 
Did you mean: 

NUCLEO board - prevent resets on USB-C (ST-LINK) is plugged / unplugged

IGärt.1
Associate II

Hi all

I am looking for a solution to prevent the NULCEO-H563ZI board from resetting every time the USB-C cable to the PC is plugged in and out. 

The virtual COM port of the ST-LINK is used to send configuration data to the board. Therefore, it is not so handy if it resets itself every time I unplug the PC. It is supposed to continue to run.

The NUCLEO is supplied by 3.3V from a host board, so no PWR-SEL jumper is set and SB1 is removed. The on-board crystal oscillator is used (SB48 and SB50 equipped with 0R's and SB49 of ST-LINK clock is removed). 

Thanks for your inputs 🙂

 

1 ACCEPTED SOLUTION

Accepted Solutions

I have none of the power jumpers in place, since I power the NUCLEO directly from a host board through the 3V3 pin of the Arduino connector.

I know that VCP means "virtual com port" 🙂 that's why I chose this setting.

As I said, the problem lies now, most probably, with my SW code. I could already confirm, that UART messages come in.

So, the actual problem of a reset happening on connecting / disconnecting the STLINK USB-C cable can to be solved by 

  • Removing R91
  • Reconfigure the on-board STLINK to "STM32 Debug + VCP"

But thanks for your replies anyway

BTW: It has to be said though, that the debugger settings will not work for HW resets anymore in this configuration. That should be obvious, since R91 interrupts the NRST line, but I'll note it here anyway. The debugger has to do a SW reset. Downloading code and debugging is still possible in this configuration.

View solution in original post

4 REPLIES 4
Uwe Bonnes
Principal III

Probably NRST from Stlink is connected to the H7 and with Stlink unpowered, NRST is pulled low. Look if there is a (solder) jumper to cut that connection.

Hi Uwe

Thanks for your answer.

I tried indeed unsoldering the 0R jumper (R91) in the NRST line from the STLINK MCU to the STM32H562. It solved only half of the problem though. 

It prevents the STM32H562 from being reset when the USB-C is disconnected. I still have a reset when I connect USB-C. 

This is super puzzling, since, at least according to the Nucleo schematic, the only other parts connected to NRST are the Ethernet IC, the reset button and two TVS diodes.

I detached the Ethernet IC by removing SB72, but I still have NRST pulled low when I connect the STLINK USB-C cable. 

Changing the STLINK Type to "STM32 Debug + VCP" stopped the NUCLEO from resetting on connecting / deconnecting the USB-C. 

But now, I have no communication when reconnecting again. Since the COM port is visible in the device manager though, I think the UART driver hangs somewhere in a Rx routine where i did not program a timeout. Deconnecting USB-C makes the UART Rx line go low, so I suppose it waits for input 🙂

Did you try different settings of the Power selection jumper?

Otherwise "STM32 Debug + VCP" should still have COM Port, as VCP implies.

 

I have none of the power jumpers in place, since I power the NUCLEO directly from a host board through the 3V3 pin of the Arduino connector.

I know that VCP means "virtual com port" 🙂 that's why I chose this setting.

As I said, the problem lies now, most probably, with my SW code. I could already confirm, that UART messages come in.

So, the actual problem of a reset happening on connecting / disconnecting the STLINK USB-C cable can to be solved by 

  • Removing R91
  • Reconfigure the on-board STLINK to "STM32 Debug + VCP"

But thanks for your replies anyway

BTW: It has to be said though, that the debugger settings will not work for HW resets anymore in this configuration. That should be obvious, since R91 interrupts the NRST line, but I'll note it here anyway. The debugger has to do a SW reset. Downloading code and debugging is still possible in this configuration.