2024-02-22 07:53 AM
We have recently received source code from the company that was developing for us. This is our first time using a STM product, so we have some learning to do. We had them build a custom external loader and bootloader in addition to the main application. I have attached an image of the three projects. What is the correct way to build and deploy each project onto a clean board with no code on it?
Solved! Go to Solution.
2024-02-22 08:15 AM
The External Loader stages in RAM, and is uploaded there by STM32 Cube Programmer. It has awareness of your hardware implementation, and brings up the external memory of your board, to the point the programmer can load blocks into RAM, and then call a function to write to external memory. Think of like a .DLL loaded on the target MCU / board.
The Boot Loader lives at the front of FLASH, is called first by the MCU, and it gates access to your Application code, and hopefully provides methods to upload new application code, and recover systems where the application code is missing, or corrupt.
You can upload the Boot Loader and App directly to your fresh board via STM32 Cube Programmer, with the assistance of the External Loader for any QuadSPI / OctoSPI NOR FLASH
2024-02-22 08:15 AM
The External Loader stages in RAM, and is uploaded there by STM32 Cube Programmer. It has awareness of your hardware implementation, and brings up the external memory of your board, to the point the programmer can load blocks into RAM, and then call a function to write to external memory. Think of like a .DLL loaded on the target MCU / board.
The Boot Loader lives at the front of FLASH, is called first by the MCU, and it gates access to your Application code, and hopefully provides methods to upload new application code, and recover systems where the application code is missing, or corrupt.
You can upload the Boot Loader and App directly to your fresh board via STM32 Cube Programmer, with the assistance of the External Loader for any QuadSPI / OctoSPI NOR FLASH
2024-02-22 08:49 AM
Okay thanks!
As for using STMCubeIDE. If I want to edit the external loader (.stldr file), would I build the external loader project (which outputs a file named SmartGauge_Ext_FlashLoader.hex) and edit the .hex file extension into a .stldr extension? I then add the external loader into the Debug Configurations for both the bootloader and main application.
2024-02-22 09:29 AM
The .HEX for the STM32 Cube Programmer External Loader is of not help. The .STLDR is an ELF Object File, and is generated by the Linker. You'd only need to rebuild this if you changed your board, and the pins or part used for the external memory. Say you went for a different size, or brand. ie Micron MT25L128 vs Winbond W25Q256
Is SmartGauge a tool you're using or the name of your product?
You should probably walk through this with your vendor.
2024-02-22 09:33 AM
So this output means nothing? I know we definitely do not plan on changing the External Memory anytime soon but would like some background knowledge on it. Thanks. SmartGauge is the name of the product.
2024-02-22 10:09 AM
The .ELF gets renamed to a .STLDR and copied into the \bin\ExternalLoader subdirectory of the STM32 Cube Programmer tool
https://www.youtube.com/watch?v=YFIvJVsvIsE
The H750 is a part that has only 128KB (a single page/sector) of FLASH tested. The die likely has 1-2MB that's actually usable in the on-the-bench sense, but it is not tested nor guaranteed for commercial use. The app code will existed completely on the external QuadSPI memory.
The Boot Loader will then typically be expected to bring up the system, clocks, pins and external memory, and then hand-off control to the app, where hopefully none of that is repeated.
2024-02-22 10:10 AM
Awesome thanks for the insight!