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

sd_ble_enable causing hang if application is jumped to from bootloader

I am using sd 7.0.0, I have a simple bootloader implementation that follows the bootloader sample code pretty closely. When I jump to my application from the bootloader and call sd_ble_enable, it hangs inside the SVC_handler. If I load my application without the bootloader, it runs fine. I do not enable sd inside my bootloader anywhere. I also know that main() inside the application is being reached. Here is my code that handles setting up the vector table address and jumping to the application.

void StartApplication(void)
{
    interrupts_disable();   
    
    sd_mbr_command_t com = {SD_MBR_COMMAND_VECTOR_TABLE_BASE_SET, CODE_START};
    sd_mbr_command(&com);
    
    JumpToApplication(CODE_START);
}

void JumpToApplication(uint32_t start_addr)
{
    __asm volatile("LDR   R2, [R0]\t\n"
          "MSR   MSP, R2\t\n"
          "LDR   R3, [R0, #0x00000004]\t\n"
          "BX    R3\t\n"
          ".ALIGN\t\n");
}

I have no idea what I am doing wrong. Any help would be greatly appreciated.

Parents
  • ONE MORE UPDATE: I later found that NVIC_SystemReset() isn't a good strategy since this should continuously boot you into the bootloader (I think) as opposed to the application. I found that calling JumpToApplication() works with no problems if, from the application, you initialize softdevice (using mbr_command) and set up the vector table directly after this.

    I think this is because there is some initialization that has to happen in SD before calling sd_ble_enable(), and since this function sets the vector table's address to SD's vector table (maybe it's needed for initialization), you have to set it back to the application. Some of this was spelled out in the bootlaoder example code, I just wasn't sure if the same would apply to the application that the bootloader is jumping to.

    So in other words, if the application is jumped to from the bootloader instead of directly from the mbr/SD, then the application also must initialize SD and set the vector table to the application vector table directly after.

Reply
  • ONE MORE UPDATE: I later found that NVIC_SystemReset() isn't a good strategy since this should continuously boot you into the bootloader (I think) as opposed to the application. I found that calling JumpToApplication() works with no problems if, from the application, you initialize softdevice (using mbr_command) and set up the vector table directly after this.

    I think this is because there is some initialization that has to happen in SD before calling sd_ble_enable(), and since this function sets the vector table's address to SD's vector table (maybe it's needed for initialization), you have to set it back to the application. Some of this was spelled out in the bootlaoder example code, I just wasn't sure if the same would apply to the application that the bootloader is jumping to.

    So in other words, if the application is jumped to from the bootloader instead of directly from the mbr/SD, then the application also must initialize SD and set the vector table to the application vector table directly after.

Children
No Data
Related