Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs

How to change the mbr jump address location

Hi,

I am using nrf5280 development kit and 17.1.0 sdk.

i am working on  ble_app_uart example code.

Its working fine no issue. Since the start address of the application is 0x27000 and i want to change it on to some other location as per my requirement which id 0xE8000.

But when i changed the starting address then its not working. Looks like control not reaches to that location.

or 

mbr not able to jump that location which i changed. 

can someone help me here. what exactly i am missing here.?

Regards

R_S

  • Hi,

    How do you try to jump to 0xE8000?

    Without knowing more I suggest you refer to the bootloader in nRF5 SDK 14.2.0 (more recent SDK versions use a different approach). You can refer to the implementation of <nRF5 SDK 14.2>\components\libraries\bootloader\nrf_bootloader_app_start.c you can see that nrf_bootloader_app_start() here takes any application start address and the way it configures the MBR and SoftDevice is different from more recent SoftDevices. You should use this approach, which can also be used with later SDK versions.

    To be more specific, In SDK >= 15.0.0, the boot process consists of forwarding interrupts to the SoftDevice using SD_MBR_COMMAND_IRQ_FORWARD_ADDRESS_SET (nrf_dfu_mbr_irq_forward_address_set()), and then always jumping to address 0x1000 (SoftDevice start) instead of the application start address. The old approach is to use the SD_MBR_COMMAND_INIT_SD and SD_MBR_COMMAND_VECTOR_TABLE_BASE_SET command, and start the application at a specific address. This is what you should use when the application is not always immediately after the SoftDevice.

    You can compare components\libraries\bootloader\nrf_bootloader_app_start.c in SDK 14.2 and a newer SDK to see both approaches.

    Einar

  • Hi Einar,

    "nrf_dfu_mbr_irq_forward_address_set()" i already used in my bootloader code example to jump on application having different address. But in this case i am not using any bootloader and i want directly jump to the application code (0xE8000 location) after softdevice. So for that whrere i need to use this function ("nrf_dfu_mbr_irq_forward_address_set()"). 

    because i have only hex file of softdevice code so, that part anyway i cannot edit.  

    2nd case:

    I am using bootloader code where i from softdevice code jump to the bootloader code and then in bootloader i am using nrf_dfu_mbr_irq_forward_address_set() and nrf_bootloader_app_start_final() function to jump on the application code. control goes to the 0xE8000 address but it got stuck inside "ble_stack_init()" function and it through an exception error.

    Regards

    R_S

  • R_S said:

    "nrf_dfu_mbr_irq_forward_address_set()" i already used in my bootloader code example to jump on application having different address. But in this case i am not using any bootloader and i want directly jump to the application code (0xE8000 location) after softdevice. So for that whrere i need to use this function ("nrf_dfu_mbr_irq_forward_address_set()"). 

    because i have only hex file of softdevice code so, that part anyway i cannot edit.  

    The boot sequence when using MBR and SoftDevice is in essense like this:

    • MBR runs first (this is located at page 0, and is part of the SoftDevice hex).
      • MBR checks if a (bootloader) address is present in either a specific register in UICR (0x10001014) or in the end of the MBR params page (0x00000FF8). 
      • If either of of these registers has a valid address (are not 0xFFFFFFFF), the MBR will jump there. If not, it will just jump to the bootloader at 0x1000.
    • SoftDevice runs and passes execution the the application, which follows immediately after the SoftDevice.

    So the only way you can boot another location than what is immediately after the SoftDevice is to use the bootloader support in the MBR. However, that does not need to actually be a bootloader. It could also be your application. This would prevent you from using a bootloader though, as the MBR features needed for some types of updates (like bootloader or SoftDevice updates) would not work in this scenario. So If you ever want to add DFU/bootloader support, then you need to do as I described in my initial post.

    R_S said:
    I am using bootloader code where i from softdevice code jump to the bootloader code and then in bootloader i am using nrf_dfu_mbr_irq_forward_address_set() and nrf_bootloader_app_start_final() function to jump on the application code. control goes to the 0xE8000 address but it got stuck inside "ble_stack_init()" function and it through an exception error.

    Yes, that is expected. That is because you are using an approach that does not work. You need to use the approach demonstrated by the bootloader in SDK 14.2, as explained in more detail in my previous reply.

  • Hi 

    I did the same way what you mentioned in your initial comment.

    nrf_dfu_mbr_init_sd(); and nrf_dfu_mbr_irq_forward_address_set();

    and after that jump to the address where my application is there but still same issue i am facing

    again it get stuck in that ble_stack_init() function,

    Regards

    R_S

  • Hi,

    Looking at the screenshot I see you get a hard fault, and not the error I expected form sd_softdevice_enable(), I did not pay attention to that initially. This shows that t PC is 0x0 and LR is 0xffffffe9, where the LR indicates return to thread mode using main stack (and FPU has been used for some reason). But why is PC 0? That should not be the case and indicates that a NULL pointer has been executed. Could it be that you have a bug in ble_stack_init() where that could happen? I suggest you debug there to pinpoint exactly where the issue is. Which function call do you do when you get the hardfault etc? Also, a look at the other CPU registers could be useful (get those for instance with "nrfjprog --readregs"). 

    So there may be another issue here. Please keep this change, though, as running nrf_dfu_mbr_init_sd() () is required in this case, as it runs the SoftDevice reset function that clears a magic word indicating that the SoftDevice has been initialized. Without it, you will see NRF_ERROR_INVALID_STATE returned from sd_softdevice_enable(). That said, you should use nrf_dfu_mbr_vector_table_set() and not nrf_dfu_mbr_irq_forward_address_set(), so please adjust this and let me know what you see then.

    Do you still get this with the above suggested change? Is the only change in your application that it is located at a different address, and does the exact same application built to start immediately after the SoftDevice work as expected?

Related