How to develop a bootloader where the secondary MCU is responsible for updating primary MCU.

[NLand.1]

Hello, I am an engineering student who has just begun working on a CubeSat project for my design class. We are working on the OBC, specifically looking at developing a bootloader at this time. The OBC components have been selected by previous teams and an outside resource we are having trouble reaching. We have been provided with a prototype board which contains 2 microcontrollers.

Primary MCU: STM32F429ZIT6U

Secondary MCU: STM32F103CBT6

Updates will be sent by UHF and received by the secondary MCU which is supposed to then update the primary, as long as the transmission was successful. As I mentioned earlier, the resource that previous teams had to help select the components and layout of the board is no longer reachable, so I was hoping I could get some advice/documents to move forward with bootloader development on here. I would also like to note that I am a 3rd year engineering student with limited exposure to programming, as most of our classes use Arduino as an education tool. What I am wondering is:

1. Is this two MCU set up necessary? From what I have read both MCU's have an internal bootloader.
2. Are the internal bootloaders capable of reverting to a previous version of the software if the update is unsuccessful? This is required since we won't have much time for communication with the CubeSat based on our location.
3. Any advice or resources related to accomplishing this task would be greatly appreciated!

I have pictures of the prototype board if that would be any help to anyone.

Thank you in advance for your time!

[Tesla DeLorean]

The internal bootloader can not revert data.

​

You realistically would need a memory device locally to stages the data so you could check for completeness and integrity. Your own loader ​would probably not want to erase itself, ever, but be able to operate in a safe/recovery mode, so you could upload an application even after a failure.

​

T​he F1 here has less memory than the F4, so not going to be able to hold a complete firmware itself. Check how much spare space you have in the F4, you might be able to assemble a new image in some of the unused sectors until you have enough to proceed, or have the ability to run two different images.