Why does .elf load fails when using STM32CubeIDE ?

[RLEP.1]

Hello, 

I have a problem with STM32CubeIDE which fails to load my .elf file into the STM32F030K6 I am trying to debug, in either debug or run modes.

Everytime, an error window pops up with following message:

"Error in final launch sequence:

Failed to execute MI command:

load xxxx.elf 

Error message from debugger back end:

Load failed

Failed to execute MI command:

load xxxx.elf 

Error message from debugger back end:

Load failed

Failed to execute MI command:

load xxxx.elf 

Error message from debugger back end:

Load failed

Load failed"

In addtition, I put in .txt attached the messages I get in the Console tab after launching debug. It seems to go wrong from the lines:

"GDB session thread running

GdbSessionManager, session started: 2

Enter STM32_HardwareReset() function 

Enter STM32_InitAfterReset() function 

NVIC_DFSR_REG = 0x00000009

GDB session terminated: Client connection lost

GdbSessionManager, session terminated: 1

GDB session terminated: Client connection lost"

I have tried many different debug configuration options, but none of them solved my problem.

When I use "STM32CubeProgrammer" to load the exact same .elf file, it works fine. Do you have any idea why it would fail with STM32CubeIDE?

I am using the latest STM32CubeIDE version: v1.10.1 (Build: 12716_20220707_0928 (UTC)). I work on Windows 11.

My STM32CubeProgramme version is v2.11.0.

Any help would be very much appreciated as I have already spent a full day trying to solve this issue.

RL

[Rim LANDOLSI]

Hello @RLEP.1​ ,

At first , let me thank you for reporting this issue.

Could you also supply the log-file? It will be created if option “Log to file�? is enabled in the debug settings.

 

Thank you,

Rim.

[RLEP.1]

Hello Rim LANDOLSI,

Thank your for your answer.

I put the log file in attachment. It seems the problem comes from a command "vKill" which is not supported?

"[6.746] read(): <752> Rx: $vKill;a410#33

[6.746] handlePacket(): Hidden/Unsupported v-command 'vKill', see RSP for details"

Best regards,

Romain

[Rim LANDOLSI]

From what we can see from the log-file the debugger tries to write to memory location "0x1ffff800" when programming the application. This will result in failure causing the debugger to disconnect. Does this address say anything to you? Can you recheck the linker script and see if any parts of the application is linked to this address?" Also. If you create a new project for a board with this MCU. Will that work?

[RLEP.1]

Hello Rim,

0x1FFFF800 corresponds to the address of the option bytes of the STM32F030K6 we use: user and read protection option "byte", user data option "byte" and write protection option "byte", each "byte" being actually 4 real bytes in size.

I confirm the problem comes from this failure to write at 0x1FFFF800 address: when we remove this memory section in the linker script, or if we do not set any value in these option bytes, .elf can be loaded through STM32CubeIDe and I can perform step by step debug.

In debug mode, our option bytes are set so that :

• User and read protection option byte (@0x1FFFF800) = 0x20DF55AA
• User data option byte (@0x1FFFF804) = 0x00FF00FF
• Write protection option byte (@0x1FFFF808) = 0x00FF00FF

Which does not set any write protection in any sector of flash memory.

Anyway it does not seem to be associated to these option byte values, I tried different values and it does not solve the problem. Also, writing these option bytes with the same values as above through STM32CubeProgrammer, it works fine.

Would you know why STM32CubeIDE fails to write these option bytes?

In any case, thank you very much for your precious help!

Best regards,

Romain

[Rim LANDOLSI]

It seems that you are  trying to program the option bytes via the application binary and that's not possible of today.

You need to use CubeProgrammer for that.