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.

[Aziz BRIGUI]

Hello @Tesla DeLorean , @Gnour ,

>>Why did STM32CubeProgrammer choose this bootloader for the download, and what exactly is it? What is its relationship with the external loader?

It is a bug and it probably happened due to the fact that programming external memories via bootloader interfaces is only supported in SFIx or for H7R/S via OpenBootloader external loaders (The ones ending with OBL in the list of external loaders in CubeProgrammer).

So to conclude :

1- The error message should change and "OpenBootloader_STM32H7RS-NUCLEO.bin" should not be loaded. Request tracked in Ticket 188770.

2- Some clarifications requested in the user manual tracked in Ticket 188772 to mainly state the current limitations for the -elbl option.

@Gnour , for H5, this feature is not yet supported in STM32CubeProgrammer.

Aziz

[Gnour]

Thank you for the clarification. @Aziz BRIGUI 

>>for H5, this feature is not yet supported in STM32CubeProgrammer.

Could you please explain what feature you're referring to for the H5? Does this mean I won't be able to work with the external loader in my case?

I also wanted to let you know that I replaced the

OpenBootloader_STM32H7RS-DK.bin

 file with the binary of my custom bootloader, keeping the same name (

OpenBootloader_STM32H7RS-DK.bin

), and it was successfully downloaded. However, I'm still not clear on whether external loaders for the STM32H7RS-DK are secured with SFI. Does that mean access to the external loader requires a secure boot, and it’s not available yet?

Lastly, I’d like a clear conclusion , can I connect my custom bootloader with an external loader for the external flash or not?

Thanks in advance.

[Aziz BRIGUI]

Hi @Gnour,

>>Could you please explain what feature you're referring to for the H5? Does this mean I won't be able to work with the external loader in my case?

The feature I'm referring to is programming external memories via bootloader interfaces (via an external loader). You can do it as you mentioned using the custom bootloader itself.

>>Lastly, I’d like a clear conclusion , can I connect my custom bootloader with an external loader for the external flash or not ?

At the moment, officially you can not. However I'm curious if the replacing you did worked. Where you able to read and write to the external memory successfully using your external loader ? 

>>However, I'm still not clear on whether external loaders for the STM32H7RS-DK are secured with SFI. Does that mean access to the external loader requires a secure boot, and it’s not available yet ?

I don't understand this questions, could you elaborate further please ?

Aziz

[Tesla DeLorean]

Make your own loader use a portion of the QSPI for a USB MSC so you can drag and drop a packaged firmware image, like .DFU, .ZIP or crypted. And then update using that intact staged image..

Then you're platform agnostic and don't need host side software in support of the update process.

[Gnour]

Thank you for the explanation @Aziz BRIGUI . Unfortunately, I wasn't able to communicate with the external flash .I couldn't perform an erase or read operation. However, the binary of my custom bootloader was successfully downloaded, though I'm not sure where exactly it was stored. It's important to note that the custom board is already running my custom bootloader, which is why it was detected in DFU mode.

I’ve also included screenshots showing the modifications I made.

 

 

 

Regarding the question about the external loaders for the STM32H7RS-DK and SFI, what I meant to ask is whether my bootloader needs to be secured for it to function like the STM32H7RS-DK. Does it require a secure boot to use the external loader effectively?