How to prevent Debug session from trying to program external memories?

[inojosh]

I will preface this by stating I did not have this problem with System Workbench on a previous project.

When using external flash (QSPI), running a Debug session will fail due to STM32CubeIDE trying and failing to program the external flash.

When running a debug session, I only want the internal flash to be programmed.

I program the external flash ahead of time, once, rather than trying to hook my custom external loader into the debugger and flash the external flash every single debug session.

How can I achieve this?

[TDK]

it should only program what's in the ELF or HEX file. You could remove the external flash section from the linker script, or mark it as noload. You could also set up the debug session to not download at all as a workaround.

[inojosh]

The QSPI section is in the elf, as there is data in it. I don't want to remove it, then the debug session will not be aware of that data, neither the build analyzer, etc.

Messing around with different linker scripts just for debugging is annoying. I still want the external flash data to be compiled, so that it can be loaded through other means.

I want the debug session to download, but only the internal flash... why should it even attempt to load the contents of external flash, when it knows it can't write to them?

This wasn't an issue with System Workbench, which is why I am confused it is a problem here. It seems like there should be a very simple solution to this problem, without having to modify the elf or linker. Simply "only program internal flash" or the like...

[Roberto C]

Hello inojosh,

I have the same trouble: i want to program external flash only when needed (if no changes i want to program only internal flah)

Have you solved it?

Thnx.

Roberto

[Tesla DeLorean]

ST really needs a serious "dog fooding" program where their developers are forced to use their own tools and fix the most annoying and egregious behaviors.

O​r hire people that can identify, fix or advocate for resolution of things that will make the process faster and easier for real world use cases.

Seem half the people developing and using tools have no CS background or skills​, don't understand assemblers, compilers, linker and loaders, or understand how similar issues have been handled on other platforms..

[Roberto C]

Probably people deveoping tool are not same who have to use them...

But I don't think it's a only ST trouble..

[RetroInTheShade]

Hi Roberto,

Yes - life is too short to unnecessarily wait for external flash to load!

In the Debug Configuration->Debugger there is a check box at the bottom called "External Loader" which normally determines if external flash is loaded.

If for some reason this approach doesn't work, you could also try adding a post build step to create a separate .elf without the external section (using arm-none-eabi-objcopy.exe). Your "Debug - No Ext Flash" configuration then can be pointed at this modified elf.

[Roberto C]

Hi RetroInTheShade,

Simply unchecking the "External Loader" check box doesn't run, then, (following your second suggest), I create a post-build command:

arm-none-eabi-objcopy  ${ProjName}.elf ${ProjName}_NOQSPI.elf --remove-section=*FlashSection

ps. All my sections names pointing to External QSPI was [variousname]FlashSection.

Then I created a debug session which load the new file ${ProjName}_NOQSPI.elf and THAT LOAD CORRECTLY.

Then thnx for support!

[inojosh]

Just jumping in to confirm (on this year old thread!) that this is what I do.

Additionally, I only program the external flash (with a CLI script, STM32CubeProgrammer, and my external flash loader) with the elf that contains just the QSPI section when necessary - if something that is stored in external flash is changed.