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

[Tesla DeLorean]

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

[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?

[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!

[Gnour]

..

[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 changed the loader script to 0x20003004. The same problem appears.

[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.

[Aziz BRIGUI]

Thanks for the swift response @Gnour,

>> Unfortunately, I wasn't able to communicate with the external flash .I couldn't perform an erase or read operation.

This is expected since like I said the feature is not officially supported for H5

>>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?

Ok I understood your request, however I don't have a definitive answer. I guess the OBL for H7RS-DK is secured since it's able to perform SFIx with the SFIx loader. What I recommend is to use your custom bootloader to interface the external memory. Since for STM32H5 this use-case is not yet supported from CubeProgrammer side.

Aziz

[Aziz BRIGUI]

Hello @Gnour 

Issue is fixed in the new STM32CubeProgrammer v2.18 available under this link. Here's the log when trying to use -elbl with a non supported device:

STM32_Programmer_CLI -c port=USB1 -elbl "C:\Program Files\STMicroelectronics\STM32Cube\STM32CubeProgrammer 2.17.0\bin\ExternalLoader\MX25LM51245G_STM32H7B0x-EVAL.stldr"
 -------------------------------------------------------------------
 STM32CubeProgrammer v2.18.0
 -------------------------------------------------------------------



USB speed : Full Speed (12MBit/s)
Manuf. ID : STMicroelectronics
Product ID : STM32 BOOTLOADER
SN : 3865356D3233
DFU protocol: 1.1
Board : --
Device ID : 0x0451
Device name : STM32F76x/STM32F77x
Flash size : 2 MBytes
Device type : MCU
Revision ID : --
Device CPU : Cortex-M7
Error: Programming external memory via bootloader interface is not supported for this device.

An improvement is also done in documentation to specify that the -elbl command via bootloader interface is only supported for STM32H7R/S

Thanks again for your inputs.

Aziz