Hi. I'm trying to analyze bootloader sequence.
I'm starting with mbs program.
In main function, the program detects button input command,
and if the button is not "very_long", it calls verify_flash_flags(), line 242 of mbs/main.c
In the function, it uses variable "flashFlags", which is a pointer for last flash page.
CopyFlashFlags_t *flashFlags = (void*)FLASH_BASE+((flashPages-1)*PAGE_SIZE);
Variable "flashPages" is caculated before, using bootloader address written in NRF_UICR_BASE+0x80
I stucked here, I can not find who write the flash page that "flashFlags" read.
It contains header; size of bootloader and softdevice; crcs; etc.
Please help me where the flash page is written.
Crazyflie bootloader sequence
Re: Crazyflie bootloader sequence
Hi,
The bootloader is described in the wiki there: https://wiki.bitcraze.io/doc:crazyflie: ... r:protocol and is implemented in crazyflie2-nrf-bootloader.
The MBS you are looking at is not the main bootloader but it can flash the bootloader and the softdevice. The idea is that the bootloader is not able to write over itself and over the bluetooth softdevice (the bootloader depends of the softdevice). So the solution is to flash a new bootloader and a new softdevice in a pre-defined way: anywhere in the writable flash, with a correct CRC32 checksum and with the address in a well-known location. This way when the copter restart the MBS verifies the checksum and if it matches it flashes softdevice and bootloader. From the MBS point of view the data appear here like magic
.
This design tries to avoid any possibility to brick the bootloader from the bootloader: in order to change the bootloader you must do it on purpose, not by mistake.
The real bootloader (the one that permits to load the flash from radio) is in this project: https://github.com/bitcraze/crazyflie2-nrf-bootloader
The bootloader is described in the wiki there: https://wiki.bitcraze.io/doc:crazyflie: ... r:protocol and is implemented in crazyflie2-nrf-bootloader.
The MBS you are looking at is not the main bootloader but it can flash the bootloader and the softdevice. The idea is that the bootloader is not able to write over itself and over the bluetooth softdevice (the bootloader depends of the softdevice). So the solution is to flash a new bootloader and a new softdevice in a pre-defined way: anywhere in the writable flash, with a correct CRC32 checksum and with the address in a well-known location. This way when the copter restart the MBS verifies the checksum and if it matches it flashes softdevice and bootloader. From the MBS point of view the data appear here like magic
.This design tries to avoid any possibility to brick the bootloader from the bootloader: in order to change the bootloader you must do it on purpose, not by mistake.
The real bootloader (the one that permits to load the flash from radio) is in this project: https://github.com/bitcraze/crazyflie2-nrf-bootloader