STM32H735-DK: Attach to ST-LINK USB debugger port fails, but STM32 programmer works.

[DMois.1]

I have a STM32H735-DK and I'm trying to load the LedToggling sample app with the STM32CubeIDE 1.5.1. Debug fails with this message.

Starting server with the following options:
 Persistent Mode : Disabled
 LogFile Name : C:\Users\davidmoisan\STM32CubeIDE\workspace_1.5.0\LedToggling\STM32CubeIDE\BootROM_ExternalRAM_InternalSRAM_Debug\st-link_gdbserver_log.txt
 Logging Level : 31
 Listen Port Number : 61234
 Status Refresh Delay : 15s
 Verbose Mode : Enabled
 SWD Debug : Enabled
 InitWhile : Enabled
 
Target connection mode: Under reset
Reading ROM table for AP 0 @0xe00fefd0
Hardware watchpoint supported by the target 
COM frequency = 24000 kHz
ST-LINK Firmware version : V3J7M2
Device ID: 0x483
PC: 0x801680c
ST-LINK device status: HALT_MODE
ST-LINK detects target voltage = 3.29 V
ST-LINK device status: HALT_MODE
ST-LINK device initialization OK
Waiting for debugger connection...
Waiting for connection on port 61234...
Accepted connection on port 61234...
Debugger connected
Debugger connection lost.
Shutting down...
 

In the GUI, CubeIDE reports "Load failed. Load failed."

I have attached the GDB server log, as well.

I can connect to the device with the STM32CubeProgrammer. What is the minimum configuration that allow this to work?

[LaurentL]

Hi,

Is it working fine with Openocd gdb server ?

Rgds,

Laurent

[DMois.1]

I changed the debugger to OpenOCD in the Run configuration.

Same results. It pauses for five seconds and gives the same error message. It does appear to connect with the board and halt the CPU, but doesn't go further.

[LaurentL]

If you want to debug, you should use debug config, not run config.

Can you attach the log text please.

Thanks,

Laurent

[DMois.1]

Update:

I have tried the Oscilloscope program. It will not load in STM32Cube or the programmer. The programmer says either the CPU is locked up, or it is under reset.

I have tried the LED toggler program with the same result.

The only thing that works in STM32Cube Programmer, is the hex file of the original firmware that I saved before erasing the internal memory. That appears to rule out the hardware.

[DMois.1]

I'll answer my own question: I needed to change the linker script to put ROM at 0x8000000 to get the oscilloscope app to load in the device. It still doesn't work, but I at least know the board's OK, my USB drivers are OK, and I can copy and paste to build an app. ST doesn't make it easy to use this board. Sigh.

[reversiverse]

Thanks for this at least, tried all possible ways, openocd+gdb, STM32CubeIDE, STM32CubeProg, JLink. Spent quite a few hours on this.

Had the same result, after fixing the linker script address program at least flashes and starts running, but not properly.

I can see it starts ResetHandler and copy some data, but the Oscilloscope example does not work either.

As a side note, shouldn't CN6 connector allow access to SWD (as it clearly shows SWDIO and SWCLK pins)? Can't find it mentioned anywhere in docs, tried it with JP3 on and off, but JLink doesn't seem to connect.

[reversiverse]

[0] from 0xfffffffe
[1] from 0xfffffff9
[2] from 0x080129d0 in HAL_TIM_Base_Start_IT+52 at /home/ondro/local/STM32CubeIDE_workspace/Oscilloscope_SignalsGenerator/Drivers/STM32H7xx_HAL_Driver/Src/stm32h7xx_hal_tim.c:481
[3] from 0x080030fe in HAL_InitTick+170 at /home/ondro/local/STM32CubeIDE_workspace/Oscilloscope_SignalsGenerator/Src/stm32h7xx_hal_timebase_tim.c:97
[4] from 0x080065e4 in HAL_Init+80 at /home/ondro/local/STM32CubeIDE_workspace/Oscilloscope_SignalsGenerator/Drivers/STM32H7xx_HAL_Driver/Src/stm32h7xx_hal.c:170
[5] from 0x08000f12 in main+18 at /home/ondro/local/STM32CubeIDE_workspace/Oscilloscope_SignalsGenerator/Src/main.c:72

The code fails with the above stack, evidently some fault, but can't see which one since I can't connect my external debuggers.

[reversiverse]

After long exhausting experiments it seems that bundled openocd (also latest git version) doesn't know how to flash the OctoSPI regions. Using JLink seems to work, at least got Weather example running. Many others flash, but don't work (usually some hard fault happens).

[mattias norlander]

Hi,

Yes, this is a known limitation. OpenOCD does not easily support external memories.

So either rely on SEGGER, or ST-LINK GDB-server for this.

But digging into this a bit I noticed that not even STM32CubeProgrammer stand-alone tool can program the external flash. And as a reminder ST-LINK GDB-server fully relies on STM32CubeProgrammer for flash operations...

So to conclude on the status right now, it seems as if the external loader file:

(C:\ST\STM32CubeIDE_1.7.0.21w21\STM32CubeIDE\plugins\com.st.stm32cube.ide.mcu.externaltools.cubeprogrammer.win32_2.0.0.202105061353\tools\bin\ExternalLoader\MX25LM51245G_STM32H735G-DK.stldr-file)

bundled with CubeProg 2.6.0 contains some bug.

I created ticket#107904 as an internal reference to analyze and fix the issue.

Thanks for reporting!

[Lk.2]

Could you help to look into this issue: https://community.st.com/s/question/0D53W00000jnB4xSAE/problem-with-running-code-execution-and-quiting-debug-using-segger-jlink-and-stm32cubeidedebugger-requested-to-halt-targettarget-halted