1

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:

  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!

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!

Nick Landrigan
  • 13
  • 3
  • Have you found the relevant docs for the bootloader that ST provide, and could you link them in the question please? – pjc50 Nov 06 '20 at 13:09
  • e.g. the version that I've found mentions "Dual bank boot" which looks like it might help, but details depend on the precise device and version. – pjc50 Nov 06 '20 at 13:12
  • I added in the documents that I have currently been looking through. Based on what I know so far it doesn't seem like there is any need for a secondary MCU to boot up the first one. I have also read some other questions on this forum mentioned that internal bootloaders might not have the capabilities for fail-safety features. I am confused as to why it wouldn't. As long as power wasn't lost on the board, wouldn't I be able to just call a reset vector to move back through the bootloader? – Nick Landrigan Nov 06 '20 at 15:34
  • Factory bootloaders are simple and immutable. If you want failsafe features, you have to design how they work (particularly how you would like them to detect failure) and implement them yourself. This question is not currently specific enough for this site; what you want is a traditional discussion forum, and to research usual solutions to the problem. – Chris Stratton Nov 06 '20 at 16:12

1 Answers1

2

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.

pjc50
  • 46,540
  • 4
  • 64
  • 126