cancel
Showing results for 
Search instead for 
Did you mean: 

How to load the external QSPI using USB-DFU method

Madhav_1
Associate II

Hello

Controller - STM32H745

We are using an external QSPI to store the application image. Currently we are flashing the image using JTAG and .stldr file as an argument to cmd ln utility STM32_Programmer_CLI.exe 

When I pull the boot0 pin HIGH I am able to load the internal flash. Is there a possibility to flash the external QSPI using USB-DFU method?

I tried this cmd but it didn't work and help section of the STM32_Programmer_CLI.exe is not clear about this topic

STM32_Programmer_CLI.exe -c port=USB1 pid=0xDF11 vid=0x0483 -w "%FW_FILE_PATH%App-CM7.hex" -v -el "%FW_FILE_PATH%qspiflashLoader-CM7.stldr"

 

1 ACCEPTED SOLUTION

Accepted Solutions
Ethan HUANG
ST Employee

According to the NOTE in Section 3.2.13 (External loader command) in UM2237 (Rev 24), using external loader over bootloader interface is not supported:

NOTE: This command (-el) is only supported with SWD/JTAG ports.

View solution in original post

10 REPLIES 10
Ethan HUANG
ST Employee

According to the NOTE in Section 3.2.13 (External loader command) in UM2237 (Rev 24), using external loader over bootloader interface is not supported:

NOTE: This command (-el) is only supported with SWD/JTAG ports.

Isn't the path here to create your own USB DFU Device implementation supporting/reporting the memory regions in your design?

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

No, first I wanted to understand if there is a possibility of using internal ROM Bootloader to load the external QSPI flash using the USB.

Ethan's answer clarifies that its not possible.

Can you suggest any example projects to achieve your own USB DFU Device implementation supporting/reporting the memory regions in your design?

Technicaly one simple way exist , based on how big image you require load. Idea is place image into imNx.hex with flasher code. Load over DFU and run. Wait for flashing to ext and load next hex as internal or next part ext...

For big external image load some intermediate fw ... that open some protocol and load ext. Then DFU internal back.

For some size you can DFU to ram and run, require more finness

MM..1,
I don't think I understood the flow! (:0)

Size of external QSPI Flash = 64MB

There will be 4 separate .hex files that needs to be loaded onto defined locations.

Combined size of the 4 files ~ 12MB.

We have our own custom bootloader placed in internal flash but there is no FW update mechanism implemented.

 

O boy or girl, flow is simple you have 1 or 2 MB flash, then create app with QSPI data + copy flash2qspi code and maybe some compresion use and flash it into MCU. (no your app , but name it flash loader) After is done, reflash internal original code....

12MB what ?? hex or bin ?? 

12MB hex files

This app's job will be only to flash the FW onto QSPI using USB-DFU?

Yes DFU load this app and bin part of external into internal flash for example on defined addr. Then code in MCU copy this part into QSPI.

STM32_Programmer_CLI.exe -c port=USB1 pid=0xDF11 vid=0x0483 -d "%FW_FILE_PATH%copy2ext-CM7.hex" -d ext.bin 0x08002000 -v -g

ofcourse ext.bin must fit internal flash...

Thanks MM..1,

I am afraid the ext.bin files will not fit as each file is more than 2MB in size.