This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Boot sequence for nRF52832

Where in the official documentation can I find what the boot order/proedure is for the nRF52832?

For instance: This post gives a coarse overview which is great but I am seeking the ability to match the instructions presented in Ozone with a flow diagram or description in documentation.

I am interested in how the bootloader is invoked - or not invoked - and how the boot events occur if the softdevice, bootloader, or none of these are present. There are bits and pieces strewn like tribal anecdotes throughout the forum, so I am hoping the description is really in front of my face and I am too thick to have recognized it.

Parents
  • Hi cswanson,

    Beside the post, you can also have a look at the softdevice specification page here to know about the reset behavior.

    The MBR is distributed as part of the softdevice. But it's not updated when you update a softdevice.

    Note that our current bootloader only works with the softdevice flashed on the chip, even if you don't use OTA DFU.

    The MBR will check the UICR to see if the bootloader is installed (and where the bootloader is) before it device to forward interrupts to the bootloader or to the Softdevice.

  • Please be aware that SD_MBR_COMMAND_VECTOR_TABLE_BASE_SET is different from sd_softdevice_vector_table_base_set().

    I think it's pretty clear in the documentation: if there is a process that the MBR is processing , it will continue and then end with a reset. If not it will check if SD_MBR_COMMAND_VECTOR_TABLE_BASE_SET is called earlier (there is a flag in the flash) and forward the interrupts to the address of the vector table it stores in flash.

    If not, it will forward the interrupt to the bootloader (skip the softdevice) if the bootloader is exist.

    If not, it will forward the interrupt to the softdevice's vector table.

    Note that we currently don't use SD_MBR_COMMAND_VECTOR_TABLE_BASE_SET anywhere in our SDK.

    We don't provide source code of MBR and softdevice, so it would be hard to find reset instruction sequence for you.

    Can you base it on the address of the instruction ? The vector table of the MBR start at 0x000000 when the vector table of the softdevice starts at 0x00001000 and the vector table of the bootloader start at the bootloader start address. I'm not very familiar with Ozone and not sure why you need that for your debugging

    gcc_startup_nrf52.s : defines the value of the vector table, which interrupt handler be called when a interrupt is triggered. The first interrupt will be the reset interrupt, handled by Reset_Handler().

Reply
  • Please be aware that SD_MBR_COMMAND_VECTOR_TABLE_BASE_SET is different from sd_softdevice_vector_table_base_set().

    I think it's pretty clear in the documentation: if there is a process that the MBR is processing , it will continue and then end with a reset. If not it will check if SD_MBR_COMMAND_VECTOR_TABLE_BASE_SET is called earlier (there is a flag in the flash) and forward the interrupts to the address of the vector table it stores in flash.

    If not, it will forward the interrupt to the bootloader (skip the softdevice) if the bootloader is exist.

    If not, it will forward the interrupt to the softdevice's vector table.

    Note that we currently don't use SD_MBR_COMMAND_VECTOR_TABLE_BASE_SET anywhere in our SDK.

    We don't provide source code of MBR and softdevice, so it would be hard to find reset instruction sequence for you.

    Can you base it on the address of the instruction ? The vector table of the MBR start at 0x000000 when the vector table of the softdevice starts at 0x00001000 and the vector table of the bootloader start at the bootloader start address. I'm not very familiar with Ozone and not sure why you need that for your debugging

    gcc_startup_nrf52.s : defines the value of the vector table, which interrupt handler be called when a interrupt is triggered. The first interrupt will be the reset interrupt, handled by Reset_Handler().

Children
No Data
Related