WB55 Nucleo: ST-Link causes MCU to reset randomly

[David C.]

I'm using an STM32WB55 Nucleo board. If I power and manage it via the built-in ST-Link USB interface, the result is very flaky. The CubeIDE debugger randomly loses its connection and, far worse, the MCU will randomly reset itself. When this reset happens, the virtual COM port (over USB) also goes off-line and generally won't recover unless I power-cycle the board.

I'm 100% certain that this is due to the ST-Link chip because the problem doesn't happen if I bypass it. If I do the following:

• Power-off the board
• Remove all the jumpers from JP5 (to disconnect ST-Link from the MCU)
• Move the power jumper JP1 from USB-STL to USB-MCU
• Power-on via the USB_User port instead of the USB_ST-Link port

then everything works great.

Of course, it's much less convenient this way. I need an external TTL serial-USB interface (attached to GPIOs PB6 and PB7) for my UART console to work and I need to flash my images via CubeProgrammer with a jumper installed across VDD and BOOT0, but I don't encounter all of the random resets I have been plagued with for the past two weeks.

I am using the latest ST-Link firmware (2J33M25)

If ST has a proper fix (maybe new ST-Link firmware?) I'd love to see it. My workaround will allow me to continue working, but it's not convenient.

[Tesla DeLorean]

DELL?

Hub, docking-station, or front-port USB?

Tried different cables, ports?

Multiple boards? The micro-USB connectors are easy to damage.

[David C.]

A Dell laptop. Attached directly to the computer's USB port.

Ports and cables change nothing. I've encountered this on two different Nucleo boards.

The connectors are not damaged. There is no problem using them to update firmware, for flashing my code, or even debugging (until the ST-Link chip resets everything).

And, as I wrote, there is no problem when I disconnect the ST-Link from the MCU.

[Tesla DeLorean]

>>A Dell laptop. Attached directly to the computer's USB port.

FTW

Boot it from a Linux Live CD

Make sure you don't have their diagnostic assistant tool installed. Check Upper/LowerFilters installed against the USB MSC driver stack.

Uninstall DELL's diagnostic/support tools.

https://community.st.com/s/question/0D50X00009XkYEoSAN/stm32f4-resetting-itself-nucleo-64

[David C.]

It looks like that may be the answer. I launched a Linux VM under VirtualBox and gave it ownership of the ST-Link USB device. Then ran minicom against /dev/ttyACM0 to monitor the console.

It's a bit early to be certain, but my app has been running longer than it ever got when talking to Windows. I'm going to let it run for another hour just to be sure.

Any clue what it could be that's causing the interference? I'm surprised ST hasn't fixed it after at least two years. Given how popular Dell Windows systems are, this has to be a pretty common problem.

I guess my next task (on Tuesday) will have to be to install the ST tools (CubeMX, CubeProgrammer, CubeIDE, etc.) in that Linux VM and do my work from in there.

[Kolab]

I get similar problem. I use laptop Lenovo, I connected the cable to USB_USER and junper 1 to MCU_USER and got working. In ST-Link port doesn't work(no advertise). How could I solve?

[David C.]

I don't know if you have the same problem. In my case, the ST-Link port shows up and mostly works, but it resets the MCU at random intervals. If you're saying it doesn't show up at all, then there may be a different problem.

Oh, BTW, @Community member​ was absolutely correct about some Windows device driver messing with it. When I run Linux under VirtualBox and give the VM ownership of the USB device (effectively removing it from Windows altogether), there are no problems.