Problem with NUCLEO-H743ZI2 and STM32CubeIDE debugging

IGrag · ‎2019-07-07

Hello,

I have recently bought the NUCLEO-H743ZI2 board and I can't use the on board STLINKV3 debugger with STM32CubeIDE, in ST-LINK GDB Server mode. However I can debug in OpenOCD mode.

The error I get is the following:

STMicroelectronics ST-LINK GDB server. Version 5.2.3

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

Waiting for debugger connection...

Debugger connected

-------------------------------------------------------------------

STM32CubeProgrammer v2.1.0

-------------------------------------------------------------------

Log output file: C:\Users\grag\AppData\Local\Temp\STM32CubeProgrammer_a10060.log

ST-Link Server is running on port : 7184

ST-LINK SN : 002B00293137510939383538

ST-LINK FW : V3J2M1

Voltage : 3.28V

SWD freq : 24000 KHz

Connect mode: Under Reset

Reset mode : Hardware reset

Device ID : 0x450

Device name : STM32H7xx

Flash size : 2 MBytes

Device type : MCU

Device CPU : Cortex-M7

Memory Programming ...

Opening and parsing file: ST-LINK_GDB_server_a10060.srec

File : ST-LINK_GDB_server_a10060.srec

Size : 18356 Bytes

Address : 0x08000000

Erasing memory corresponding to segment 0:

Erasing internal memory sector 0

Download in Progress:

File download complete

Time elapsed during download operation: 00:00:01.050

Verifying ...

Download verified successfully

Target unknown error 19

Error in initializing ST-LINK device.

Reason: Unknown. Please check power and cabling to target.

Failed to restart ST-LINK connection

Error in STM32CubeProgrammer

Target is not responding, retrying...

Debugger connection lost.

Shutting down...

Does anybody know what to look?

Attached is the log file from the debugger.

Best Regards,

Ioannis Gragopoulos

IGrag · ‎2019-07-07

Hi,

It worked after firmware update to version V3.J4.M2.

Thank you.

View solution in original post

Tesla DeLorean · ‎2019-07-07

You could perhaps try backing off the speed and update the ST-LINK firmware to current.

Does it fails when downloading the original fw back onto the NUCLEO?

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

IGrag · ‎2019-07-07

Hi,

It worked after firmware update to version V3.J4.M2.

Thank you.

JVanL.1 · ‎2019-12-11

I and two coworkers were having this problem in spades sometimes, and other times things would work fine for a while. We also had problems with the virtual comm port disconnecting spontaneously. These problems tended to happen more on laptop systems, but one older (but up to date) desktop system never had the problems. We're using the Nucleo STM32F401RE board.

Long story short - update the Nucleo board's dbugger firmware to not include the mass storage option. For us this immediately cleared up all our problems. This is an option when you update the firmware (whether the board's firmware needs updating or not).

There are lots of possible reasons your code can cause the debugger to loose connection (like trying to use the SWD/JTAG pins for GPIOs, screwing up the clocks, etc). But if you're on top of all those possibilities like we thought we were, and the problem still persists try the above suggestion.

I arrived at this when I started trying to compare differences in the USB connection between my system that never had the problem and the one that did. I was going to dive into WireShark, but first took a look at voltage levels and signal quality of the USB lines. No problems seen there, but while the data lines were hooked up to a scope there was all of a sudden a whole lot of activity on the data lines, even though no debug or VCP connection were active, This made me thing of the virtual disk (MBED disk or Mass storage option) that was there, and maybe something in the windows system was scanning it (anti-virus, defrag, who knows).. The easy way to eliminate that was to eliminate the disk, which I discovered was an option when you update the Nucleo board firmware. Apparently, for us at least, whatever the system was doing with that disk was causing the debugger and vcp connections to have problems.

btw - We had also previously tried updating the Nucleo firmware without changing the mass storage option, and the problem persisted. So it wasn't just the firmware update that fixed things for us.

MEdgerton · ‎2020-06-13

Thank you for this information. I have just been seeing exactly this behaviour. Thought it was fixed then it started playing up.

The only time I see the issue though is when I hit the red SWD console trace button. Normal debug is fine.

Was this the same for you?

I cannot see the option not to have the Mass Storage Device in the latest 007 upgrade tool. Which tool/software did you use to upgrade and where did you get the firmware files from?

Thank you,

Mark