Skip to main content
IGrag
IGrag
Associate
July 7, 2019
Solved

Problem with NUCLEO-H743ZI2 and STM32CubeIDE debugging

  • July 7, 2019
  • 3 replies
  • 1929 views

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

Copyright (c) 2019, STMicroelectronics. All rights reserved.

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...

Target is not responding, retrying...

Target is not responding, retrying...

Target is not responding, retrying...

Target is not responding, retrying...

Target is not responding, retrying...

Target is not responding, retrying...

Target is not responding, retrying...

Target is not responding, retrying...

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

This topic has been closed for replies.
Best answer by IGrag

Hi,

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

Thank you.

3 replies

Tesla DeLorean
Tesla DeLorean
Guru
July 8, 2019

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 VenmoUp vote any posts that you find helpful, it shows what's working..
IGrag
IGragAuthorAnswer
Associate
July 8, 2019

Hi,

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

Thank you.

JVanL.1
JVanL.1
Visitor II
December 11, 2019

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
MEdgerton
Associate III
June 14, 2020

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

Terms & ConditionsAccessibility statement