Replacing MBR with custom bootloader

Hi,

I'm developing a custom MBR/bootloader for NRF52811 which is used as a second/radio MCU on the board. The MCU will need to run applications with and without the softdevice, based on current usecase (ble and non-BLE protocols). The official uart bootloader takes way too much flash (25k + 8k of config space), even after removing crypto (still 15k+config), leaving us with only few kB of Flash for application logic.

So the current approach is to write a custom MBR which would contain a simple UART protocol to rewrite the flash, nothing fancy, just writing to flash and getting CRC of the data written, a data blob with app or app+softdevice would be written from 0x1000.

So, my question is how the official MBR actually works. Is it enough to change VTOR to 0x1000, jump to reset handler in vector table at that address and stop worrying (assuming the softdevice, if present, handles forwarding all interrupts to app)? Is there anything else, except the interrupt vectors redirection needed to support the softdevice?

Thank you

Parents
  • The MBR has an important role to play when replacing/upgrading the bootloader and the softdevice - its the code piece which does the actual swapping of flash pages. Not easy to replace/rewrite.

    if you run out of flash space, consider external flash or a bigger chip variant.

  • It might have an important role for upgrading bootloader and softdevice, but I don't really care in this case - the bootloader won't be present, or to be precise, the fw/softdevice upgrade logic would be placed in the MBR itself.

    I don't need updates over bluetooth, I don't mind corrupting softdevice/app if the upgrade is aborted in the middle - I can always reset MCU by reset pin and write the fw binary again - the NRF is a secondary MCU on a larger board and the main MCU is there to make sure the correct firmware is flashed and working correctly.

Reply
  • It might have an important role for upgrading bootloader and softdevice, but I don't really care in this case - the bootloader won't be present, or to be precise, the fw/softdevice upgrade logic would be placed in the MBR itself.

    I don't need updates over bluetooth, I don't mind corrupting softdevice/app if the upgrade is aborted in the middle - I can always reset MCU by reset pin and write the fw binary again - the NRF is a secondary MCU on a larger board and the main MCU is there to make sure the correct firmware is flashed and working correctly.

Children
No Data
Related