How to reduce the memory flashing time when debug

[Ggual.2]

Hi to all community.

I am new with the touchgfx and the graphic ST microcontrollers.

I have develop an application on STM32H7 MCU with touchgfx. The mcu use an external 16Mb flash memory to store the application, touchgfx, images etc...

The graphic interface are ended but when I launch the debugger for test some changes in the application, some minutes are necessary because the CubeIDE reflash entire memory, application and graphics, and this is a bit frustrating.

So I ask you if exist a system to flash the touchgfx and graphical elements one time when these are finished, and afterwards flash only application program for speed up the debugging.

I use ST link and I have try to speed up the frequency to 24MHz but it doesn't get much better.

Thanks

[MM..1]

Ofcourse , for this you can create more debug/run configurations and on desired setup checkbox external loader off.

[Ggual.2]

Hi MM,

The 16Mb external flash are used in memory mapped mode, so the MCU run on it: main program and graphics. In the internal flash only the bootloader is executed at startup. So when I make a little change on the main code the IDE re-flash all the entire 16 Mb memory before the debug run and much time elapse. Can I speed up this?

[MM..1]

In normal situation is in external only graphics. When you place code here then sorry your question is ...

But whe you partition external then maybe you can reflash only one part and not full 16M, for this you need know external loader technology

[Ggual.2]

Hi MM,

the MCU have 128kb of internal flash. Into the memory details window I can see that ".text" size is 181.65kb. With max optimization the size is 171.38kb. 5.2Mb are the size of the images. I think that touchgfx are a bit heavy for this MCU. So I must store both code and graphics into external flash. But how I can do for reflash only the application without graphics if these are in the same external flash?

[uilter]

@Ggual.2 did you find any path to flash only internal memory?

I have this same issues here. It spend to much time to flash the external memory.
My "workaround" was use a JLINK probe to flash the internal memory when I don't have any edition at external NOR. The JLINK ignores the external address and just flash the internal memory.

I tried to disable the external loader or remove it from CubeIDE, but I got a error message.

Let me know if you or anything else from community have a better way, to keep using the ST-LINK V3.

Thanks!

[JTP1]

Hello

One way is to use arm-none-eabi-objcopy- command to create Elf -file which contains only internal flash, like this:

arm-none-eabi-objcopy.exe --remove-section=ExtFlashSection "yourFilename.elf" "IntFlash.elf"

and place this to the post-build command.

[uilter]

It works for us! Thanks @JTP1 !

In our case, we add more "--remove-section" at pos-build command line because we have 3 section mapped on linker file.

Also to this, we create a Build Configuration to help switch between full program memory (internal and external) and only internal memory.

In debug configuration, main tab:
- create a new Debug Configuration
- select the C/C++ Application ELF file (the new one with internal memory)

In debug configuration, debugger tab:
- remove the external loader

[redmig]

With STM32F769 Disco, in the linker script, after a first flash where I write the external memory, I added (NOLOAD) to the memory sections saved in the QUADSPI (ExtFlashSection, FontFlashSection, TextFlashSection ). This definetly improved the flash time. I just have to remeber to remove the NOLOAD option when I change something in the GUI.

[Ggual.2]

Sorry,

I have try to write NOLOAD to ExtFlashSection in the linker script, but the result is graphical elements damaged. This is because I have all the code logic + graphics on the same external memory. The internal flash memory is to small for my application.

Exist a solution for this problem?

Exist a debugger probe that reduce significatly the flashing time? On ST website I see I-Jet debugger probe. work it with stm32H7b0 and stm32cubeide 1.13.0?