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!

[Tesla DeLorean]

@STea @Aziz BRIGUI where would STM32H7RS loader be coming from or selected in this context, it seems bizarre

[Gnour]

I already have my own bootloader with a DFU device, and I was able to perform erase, read, and write operations in the external memory. However, this was done in a hard-coded manner, meaning that the bootloader is set to write either to the internal flash or the external flash, but not both. This is why I decided to use the external loader, so I could write to both memories. I hope my explanation is clear.

Also, could you please provide an example of how to build an external loader using STM32CubeIDE?

Additionally, my question about the STM32H7RS-DK is still open. Why did STM32CubeProgrammer choose this bootloader for the download, and what exactly is it? What is its relationship with the external loader?

[Gnour]

I think the bootloader is coming from the repository named OBL in the STM32CubeProgrammer repository. But the question is, why did it select this bootloader?

[Tesla DeLorean]

The DFU device should be able to report available memory regions via descriptors, how well integrated that is end-to-end, I don't know.

>>Also, could you please provide an example of how to build an external loader using STM32CubeIDE?

That's really not my business. I'm building my .STLDR with GNU/GCC and MAKE directly. A couple I've rebuilt using KEIL's ARMARM assembler, and the .FLM I'm building with KEIL

>>Additionally, my question about the STM32H7RS-DK is still open.

Yes, they neatly side stepped that. Assuming it's a bug, misidentifying the DEVID, although OpenBootloader more generally might facilitate a staged-loader model, not something I've dug deeply into.

[Tesla DeLorean]

Ok, but that's not passed in the command line, and it reads the Device Id for the STM32H5 prior to this.

I'm not sure if this is part of the problem, or tangential.

Right now it's odd and unexplained.