Issue with the external loader with STM32H563

[Gnour]

Hello everyone,

I'm encountering an issue while using an external loader to program an external flash memory (MX25L6433F) on an STM32H563IGK6 board. My objective is to access this external flash (OCTOSPI1) with DFU for operations like erasing, writing, and reading, specifically to download my application into the external flash.

However, when I run the command using STM32CubeProgrammer via the command line, the program loads a bootloader named "STM32H7RS-DK" instead of using my custom bootloader, which is already running on the board.

I have a few questions regarding this behavior:

Why does STM32CubeProgrammer choose to load this "STM32H7RS-DK" bootloader? I understand it is a secure bootloader, but I'm unclear on why it's being selected.
Does this mean my custom bootloader will be ignored or replaced?
What exactly does this choice of bootloader by the program mean, and how can I access my external flash (erase, write, read) while still using my own bootloader?
I've attached a screenshot for more details on the messages displayed.

Thanks in advance for your help!

[STea]

Hello @Gnour ,

Can you please share with us the steps you followed to create the external loader and how did you include it in the right paths of cubeprogrammer .

In this article you will see the necessary steps needed to use a custom external loader. (try using the GUI instead)
in your issue description there is some ambiguity between the bootloader and external loader can you please clarify this to further help you resolve your issue.
Regards

[Gnour]

UPDATE : 

I have built my own external loader specifically for my project, ensuring that it matches the configuration of the external flash (MX25L6433F) in my custom bootloader. Despite this, I'm still encountering the error "Cannot copy external loader to SRAM" and the program loads the same bootloader named "STM32H7RS-DK" when connecting with STM32CubeProgrammer in DFU mode. I've attached the latest screenshot showing this issue.

Does anyone have insights into what might be causing this problem? Any advice would be appreciated!

[STea]

Hello @Gnour ,

Can you please try the same manipulations using the GUI as described in the shared article and confirm if you are seeing the same errors?
Regards 

[Tesla DeLorean]

If it's not loading my loader it's because the path is wrong and the file is not where specified.

Check if you need to add quotes around paths/names with spaces.

The H5 external loaders need to live at 0x20003004, as I recall, and not 0x20000004 or 0x24000004, check the loader script (.LD)

[Gnour]

I used CubeIDE to generate the external loader, and you can see the project structure in the attached photo. I copied the generated file to the path: C:\Program Files\STMicroelectronics\STM32Cube\STM32CubeProgrammer\bin\ExternalLoader. STM32CubeProgrammer was able to parse the file, detect the size of the external flash, and proceed with the operations.

However, I have a few questions:

How does the external loader actually work in this context? Will it exit my custom bootloader, or does it somehow integrate with it?
What is the "OpenBootloader STM32H7RS-DK" that was mentioned in the command line? How is it related to the process?

[Gnour]

I changed the loader script to 0x20003004. The same problem appears.

  

 

[Tesla DeLorean]

I'm not sure of the reasoning behind the OpenBootloader in this situation.

I will note however that External Loaders have typically NOT been supported in the STM32 DFU mode of the System Loader, nor the UART methods.

The STLDR have typically been used by the ST-LINK SWD/JTAG methods. The application stages the external loader in RAM, and uses other areas of RAM to transfer the content to be programmed, and calls the functions in the external loader to be executed.

To support memories beyond the scope of the ROM's System Loader, you would typically make your own DFU Device, which furnished the address/sizes of the memory regions you support, and back with the QSPI memory devices.