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 that 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 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:
- Is this two-MCU set up necessary? From what I have read both MCU's have an internal bootloader.
- 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.
- Any advice or resources related to accomplishing this task would be greatly appreciated!
All of my online searches so far have led me to the internal bootloaders being activated through a pushbutton and programs being updated by a computer.
Here are some of the documents I have found regarding the ST internal bootloaders:
STM32 microcontroller system memory boot mode: https://www.st.com/resource/en/application_note/cd00167594-stm32-microcontroller-system-memory-boot-mode-stmicroelectronics.pdf
Secondary MCU starts on page 65, Primary MCU starts on page 153
On-the-fly firmware update for dual bank STM32 microcontrollers:
https://www.st.com/resource/en/application_note/dm00230416-onthefly-firmware-update-for-dual-bank-stm32-microcontrollers-stmicroelectronics.pdf
STM32™ and STM8™ Flash loader demonstrator:
https://www.st.com/resource/en/user_manual/cd00171488-stm32-and-stm8-flash-loader-demonstrator-stmicroelectronics.pdf
Windows API for STMicroelectronics microcontroller bootloaders:
https://docplayer.net/161763432-Um0516-user-manual-windows-api-for-stmicroelectronics-microcontroller-bootloaders-introduction.html
I have pictures of the prototype board and an old block diagram of the OBC if that would be any help to anyone.
Thank you in advance for your time!
Best Answer
So the classic failure mode is:
new update contains either a bug or corruption during download and installation
new update boots up
before it reaches a point where you can communicate with it, it crashes
either (a) it goes back to the boot point, and does the same thing again
(b) it locks up, and eventually gets reset by the hardware watchdog
If you have a failsafe bootloader, it will have some way of detecting that the last boot did not reach a point which could be deemed "success", at which point it switches to booting the other, older copy of the firmware.
It may not be 100% necessary to have a separate microcontroller for this, but it does enable you to replace only one of their firmwares at a time.