https://github.com/thijses/stm32wb55_custom_arduino_bootloader

an example of custom bootloader for the STM32WB55 which uses regular arduino-platform code for the bootloader
https://github.com/thijses/stm32wb55_custom_arduino_bootloader

arduino bootloader platformio stm32wb55

Last synced: about 2 months ago
JSON representation

an example of custom bootloader for the STM32WB55 which uses regular arduino-platform code for the bootloader

• Host: GitHub
• URL: https://github.com/thijses/stm32wb55_custom_arduino_bootloader
• Owner: thijses
• Created: 2023-09-14T14:21:47.000Z (over 1 year ago)
• Default Branch: main
• Last Pushed: 2023-09-18T11:27:34.000Z (over 1 year ago)
• Last Synced: 2023-09-18T13:10:54.895Z (over 1 year ago)
• Topics: arduino, bootloader, platformio, stm32wb55
• Language: C++
• Homepage:
• Size: 26.4 KB
• Stars: 0
• Watchers: 1
• Forks: 0
• Open Issues: 0
• Metadata Files:
  • Readme: README.md

Awesome Lists containing this project

README

        
# STM32WB55_custom_arduino_bootloader

an example of custom bootloader implementation for the STM32WB55 which uses regular arduino-platform code for the bootloader.

I've named it (somewhat egocentrically): Thijs Over-The-Air Loader-of-Boots (because my name is Thijs and i'm using this to make a BLE OTA bootloader)

There exist bootloaders for STM32 devices, and ST's examples sketches includes an OTA bootloader for the STM32WB55 specifically, HOWEVER, most of these examples write the bootloader in lower-level C, and alter source files to insert the bootloader early in the startup process. This platformIO project however, starts up like a normal STM32-arduino-platform device, which lets you write the bootloader in the trusty setup() & loop() functions we've all grown accustomed to. Existing bootloaders are often inserted early in the startup process because (it's faster, but also because) it means you can run the regular initialization functions afterwards. This code differs, in that it initializes to full arduino-levels (of comfort/ease), and then (in order to jump to the user-application) un-initializes everything again, just so it can be safely re-initialized by the user-application. I spent several days pouring over the reference manual and the various layers of STM32 abstraction to find the default register settings and the correct order to deactivate things. (it mostly took a while because the STM32WB55 will crash so hard that even the ST-link debugger becomes unresponsive).

Jumping to the user program takes about ~1.5ms if using 'leave_LSE_same'  (asin "jumpToProgram(leave_LSE_same = true)"). RE-initializing the LSE after it's been turned off takes about ~124ms (with both the nucleo dev kit and my custom boards). The whole RTC peripheral is reset, so leaving the LSE crystal running should be fine, but there might be some niche problematic scenarios (e.g. involving the LSE Clock Security System).

Usage: (see example project)

- (to compile the example script, copy the whole library into the lib folder of that project)

- in the platformio.ini file, there are 2 targets. One is for uploading bootloader code and the other is for uploading application code.

- Upload the user-app (by selecting the 'OTA_z_STM32WB55' target) (Note: if your uploader offset settings are correct, this should not overwrite bootloaders)

- then upload the bootloader (by selecting the 'BOOTL_STM32WB55' target)

- watch the serial monitor show it booting twice

current problems i'm trying to solve:

- find a way to perform SHCI_C2_Reinit() (from the STM32duinoBLE library, but without importing the whole library), or perhaps a more universal CPU2 reset

- add some basic watchdog example code

- add some basic flash/backup-domain flag example code