Stm32h7 custom bootloader

[iTTy]

Hi there,
I'm new on stm32 platform and I'm also new on the bootloaders applications.
I'm trying to arrange a custom bootloader for stm32h755 mcu to permit remote firmware updates of our products.

My idea is to implement the bootloader application on the M7 core only, while end application require both M7 and M4 cores.
By this way M7 flash will be shared between boot and final application while M4 flash will be dedicated to the end application only.
M7 bootloader shall program both M7 and M4 applications.

At the startup (power on or after system reset) bootloader on the M7 and M4 application will start: M4 will enter in stop mode waiting for the wake-up from the M7 as ususal, but bootloader will not release it.
After its execution, bootloader M7 will jump to the (new) m7 application that will release the new programmed M4 application.
To jump from the running application to the bootloader, M4 core shall perform a system reset.
I already tried this mechanism and seems work as described.
it could be a right approach?

Anyway my concern is about the M4 core wake-up: exiting from STOP state a reset is performed? (stack pointer, program counter, variables initialization and so on...)

Thankyou in advance for your support!

iTTy

PS: Why I'm not able to select the proper label for this post? "Bootloader", "STM32H7 Series" lables and so on are not available in post composition window... sorry!

[Tesla DeLorean]

Apparently Multi-Billion Dollar Corporations only have a very limited subset of bad forum software to choose from, stuff that looks pretty on the outside, but's not good functionally, and nobody on staff can fix or modify in a timely manner.. This software is designed around the expectations there will be SIX (6) users, and that we are not familiar how proper forum software and communities should operate..

I would look to having somewhere to stage firmware (QSPI, OCTO, SDCARD, eMMC, USB-MSC) during an upgrade. A place you can put it, and validate that it is complete and intact before starting.

Would put loaders in both cores startup space, have those validate application images and startup-mode before proceeding.

The M7 core / loader would be responsible for doing the upgrade, checking the new image is newer and intact, and then process to erase and update the internal flash areas for the apps in both cores. This would need to be restartable and recoverable. The M7 core loader should also be able to detect failure cases, and provide for alternative methods to pull in and update images.

Slack areas of Internal Flash, if large enough, could also contain updates, or secondary loaders, although the stalling of execution can be problematic for real-time peripherals and networking / communications.

[iTTy]

Hi @Tesla DeLorean ,

thanks for your reply.

At the moment I'm just trying to understand how to arrange the bootloader for the dual core architecture working on a Nucleo H755 board.
Since implementing two concurrent loaders feel more complicated, i would preferer to have a simple and reliable single core loader.
My doubt is about the application launching after bootloader phase: on the M7 core I don't see problems since application switching cause a "white start" of the application like after a power on cycle.
My concern is on the M4 core:waking it up from the STOP mode is enought to start the new application or a system reset is required to have it corretcly initialized?