Purpose of separate 'boot' and 'appli' directories?

[msalazar]

Hi Support,

I am unfamiliar with this project structure where the generated project contains separate boot/ and appli/ directories. I created the project using STM32CubeMX with the CMake toolchain selected, and noticed that two separate .elf files are produced after building.

I am unsure which of these should be used when flashing the board using STM32CubeProgrammer. Currently, I am able to successfully flash the device using the .elf located in the /boot/ build directory, but I cannot flash the .elf located in /appli/.

Could you clarify the purpose of the boot/ and appli/ directories and which firmware image is intended to be flashed? Additionally, is there a way to generate a more traditional single-application project structure (i.e., without separate boot and application directories) when targeting the STM32H7S3L8?

Any guidance or suggestions would be greatly appreciated.

[NesrynELMK]

Hello @msalazar ,

 The reason for this split is to simplify the development of applications that run from boot or external flash memory. For this purpose, it is recommended to divide the firmware into two sub‑projects:

• boot/:
  Contains the bootloader code, responsible for system initialization (such as CPU clock configuration, MPU setup, and external memory interfaces) and for managing the startup of the application.

• appli/:
  Contains the main application code, which is stored and executed from external memory.

  The reason for this split is to simplify the development of applications that run from boot or external flash memory. For this purpose, it is recommended to divide the firmware into two sub‑projects:

To create a single‑application project:

1. In STM32CubeMX, generate a project and select only the “Appli” (application) project.
2. Use STM32CubeMX to select the board and peripherals, and configure the peripherals for the application context prior to code initialization generation and application code completion. 
3. you can reuse the default Boot_XIP.hex  image from the “Template_XIP” project as the boot stage, which performs the basic initialization before jumping to their own application code.

Useful references

• ST Community article on debugging an STM32H7Rx/Sx project without the boot/appli split:
  https://community.st.com/t5/stm32-mcus/stm32cubeide-how-to-debug-an-stm32h7rx-sx-project-without/ta-p/737120

• UM3294 – STM32H7Rx/Sx user manual, providing detailed information on boot, XIP, and execution from external memory.

Br,

[msalazar]

Thank you for your response; however I am little confused. If I am using the STM32CubeProgrammer to flash, how do I combine step 3, which uses the BOOT_XIP.hex image and link it to MY application code. What is the system flow for flashing the application code using that provided template file.

Does this require me to update certain files from the generated project?

[NesrynELMK]

Hello @msalazar,

Use STM32CubeProgrammer to load the BOOT_XIP.hex (bootloader) into the internal flash at address 0x0800_0000.

 

Br,