Slow debugging start

[ICohe.1]

Takes about 15 seconds from click on the debug button in CubeIDE to the first break point ( the call to  HAL_Init() ). Custom board, F401RTE, original ST Link V2, using SWD.

Would it be faster using a NUCLEO board ?

[waclawek.jan]

Subsequent code runs OK?

What's on the board? What is in the startup code? You surely can place a breakpoint at the reset vector's target and then single-step from there, can't you?

I don't use CubeIDE.

JW

[Uwe Bonnes]

Does you program sleep for extended periods? When not connecting under reset, debugger needs the CPU awaken to connect

[ICohe.1]

Everything works fine.

The only issue is the time it take from pressing the debug button and until the program is reaching the first line in my program. A call to  HAL_Init()

which is the first line in main(). The board is simple with only eeprom and RTC.

I didn't place any breakpoint it just stop there (on the line with a call to  HAL_Init()) . It is OK to stop there automatically whe I debug. The issue is the time it takes to get there

Here is the printout from the debugger:

 
STMicroelectronics ST-LINK GDB server. Version 5.5.0
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
        InitWhile                  : Enabled
 
Waiting for debugger connection...
Debugger connected
      -------------------------------------------------------------------
                       STM32CubeProgrammer v2.4.0                  
      -------------------------------------------------------------------
 
ST-LINK SN  : 54FF72067880565340510267
ST-LINK FW  : V2J36S7
Voltage     : 3.22V
SWD freq    : 4000 KHz
Connect mode: Under Reset
Reset mode  : Hardware reset
Device ID   : 0x433
Device name : STM32F401xD/E
Flash size  : 512 KBytes
Device type : MCU
Device CPU  : Cortex-M4
 
 
Mass erase ... 
 
Mass erase successfully achieved
      -------------------------------------------------------------------
                       STM32CubeProgrammer v2.4.0                  
      -------------------------------------------------------------------
 
ST-LINK SN  : 54FF72067880565340510267
ST-LINK FW  : V2J36S7
Voltage     : 3.22V
SWD freq    : 4000 KHz
Connect mode: Under Reset
Reset mode  : Hardware reset
Device ID   : 0x433
Device name : STM32F401xD/E
Flash size  : 512 KBytes
Device type : MCU
Device CPU  : Cortex-M4
 
 
 
Memory Programming ...
Opening and parsing file: ST-LINK_GDB_server_a17956.srec
  File          : ST-LINK_GDB_server_a17956.srec
  Size          : 25376 Bytes
  Address       : 0x08000000 
 
 
Erasing memory corresponding to segment 0:
Erasing internal memory sectors [0 1]
Download in Progress:
 
 
File download complete
Time elapsed during download operation: 00:00:01.213
 
 
 
Verifying ...
 
 
 
 
Download verified successfully 
 
 

Erase and download are performed even when no change was made

[TDK]

15 seconds seems long. But Eclipse, on which CubeIDE is built, is very slow and clunky in general. Delays of seconds to do operations is not uncommon.

[Pavel A.]

> Erase and download are performed even when no change was made

This. Mass erase is slow.

> I didn't place any breakpoint it just stop there (on the line with a call to HAL_Init()) . It is OK to stop there automatically whe I debug.

This is a temporary breakpoint enabled by checkbox "break at main" in the debug config.

If I understand correctly, CubeIDE debugger waits for the first breakpoint hit to fully start debugging.

Until the first breakpoint, it cannot do anything and all debug controls are disabled.

-- pa

[ICohe.1]

Is there a better /faster way to debug both hardwae and software ?

[waclawek.jan]

As PavelA said above, avoid mass erase.

I don't know how, I don't use any of the eclipsoids.

JW

[TDK]

In my experience with several Eclipse-based IDEs, none of them have performed a full chip erase by default. Seems like yours is both doing a full chip erase, then doing an erase on individual sectors as well.

Erasing memory corresponding to segment 0:
Erasing internal memory sectors [0 1]

You'd need to disable the first full chip erase. Not sure how. Look for options in the run configuration settings.

[ICohe.1]

Managed to remove the: monitor flash mass_erase  from the debug configuration.

select Run from the main menu.

then select Debug configuration...

Click on the Startup tab

delete the:

monitor flash mass_erase 

command in the initialization Command box