BLE NRF52805 DFU bootloader can't jump to the app

RE: BLE NRF52805 DFU bootloader can't jump to the app

astomi — Thu, 03 Jul 2025 22:21:50 GMT

Well, as expected, it was a typo in the app flash placement. Once I have fixed it to 0x00019000, it worked. Duh!

RE: BLE NRF52805 DFU bootloader can't jump to the app

astomi — Thu, 03 Jul 2025 21:01:40 GMT

To answer my own question. s112 specs suggest that it is done by the bootloader by calling sd_softdevice_vector_table_base_set() and one should expect to find "Setting vector table to main app:" line in the bootloader's log. But it is not there in my case. Further reading says it is actually hardcoded within softdevice. nrf52810 memory map gives me 0x00019000. And it correlates with log '<debug> nrf_dfu_validation: Write address set to 0x00019000'

RE: BLE NRF52805 DFU bootloader can't jump to the app

astomi — Thu, 03 Jul 2025 16:38:21 GMT

OK, I looked at the code. Apparently everything is hardcoded. Stack and start address are taken from Softdevice vector table, which is set equal to MBR_SIZE, which is hardcoded to 0x1000). But that doesnt' make much sense to me unless I am missing something here - it is supposed to be Stack and Start of my app, not Softdevice. Unless Softdevice vector table has redirects to actual locations - but how? It is very likely that nothing is wrong with bootloader...

RE: BLE NRF52805 DFU bootloader can't jump to the app

astomi — Thu, 03 Jul 2025 15:49:47 GMT

Ignore remark above. I forgot it is not a debug buiid but rather a 'Debug' Release

RE: BLE NRF52805 DFU bootloader can't jump to the app

astomi — Thu, 03 Jul 2025 15:44:11 GMT

That matches my observations

RE: BLE NRF52805 DFU bootloader can't jump to the app

Vidar Berg — Thu, 03 Jul 2025 15:44:05 GMT

The input arguments (reset_handler and new_msp) are not pushed on the stack. Check r0 and r1 instead. You can also try to single step from this function to find out when the fault exception is raised.

RE: BLE NRF52805 DFU bootloader can't jump to the app

astomi — Thu, 03 Jul 2025 15:41:46 GMT

It seems to be some sort of missing config thing.

I have traced bootloader execution down to

jump_to_addr(new_msp, reset_handler); // Jump directly to the App's Reset Handler.

in nrf_bootloader_app_start_final.c. And I have added both parameters to the watch list - neither is recognised.

RE: BLE NRF52805 DFU bootloader can't jump to the app

Vidar Berg — Thu, 03 Jul 2025 15:37:57 GMT

[quote userid="113304" url="~/f/nordic-q-a/122708/ble-nrf52805-dfu-bootloader-can-t-jump-to-the-app/541359"]pc=0x00000a60[/quote]

That's because you have the breakpoint on Hardfault enabled.

RE: BLE NRF52805 DFU bootloader can't jump to the app

astomi — Thu, 03 Jul 2025 15:17:29 GMT

[quote userid="4240" url="~/f/nordic-q-a/122708/ble-nrf52805-dfu-bootloader-can-t-jump-to-the-app/541325"]please use Segger Embedded Studio version 5.x[/quote]

Built by 5.68 - no changes

[quote userid="4240" url="~/f/nordic-q-a/122708/ble-nrf52805-dfu-bootloader-can-t-jump-to-the-app/541325"]I recommend you start a debug session in SES[/quote]

pc=0x00000a60

[quote userid="4240" url="~/f/nordic-q-a/122708/ble-nrf52805-dfu-bootloader-can-t-jump-to-the-app/541325"]you should reserve the first 8 bytes of RAM in your application[/quote]

No changes

RE: BLE NRF52805 DFU bootloader can't jump to the app

Vidar Berg — Thu, 03 Jul 2025 12:35:27 GMT

Hello,

I don't think it's what's causing the problem with not booting the app in this, but please use Segger Embedded Studio version 5.x to build your app and bootloader as versions 6.20 and later have known compatibility issues with this SDK.

[quote user=""]

If I generate bootloader setting and program them as well, the bootloader never starts DFU even on a blank (erased) chip with the same message as above.

Judging by the power consumption (about 2.5ma) nrf52805 is stuck in some sort of waiting loop or similar.

[/quote]

I recommend you start a debug session in SES and pause the debugger when you have reached this state. You can then check the Program Counter register (PC) in the register view to determine where the code hangs.

[quote user=""]Is there some bootloader/app integration guide? Or bootloader is smart enough to relocate off-the-shelf app to jump to?[/quote]

The bootloader is branching to address 0x1000 + 4 which is the address of the Softdevice's reset handler, so this is correct.

[quote user=""]What NO_VTOR_CONFIG actually does? Just sets vector table? I presume Softdevce sets vector table so both bootloader and app should be compiled with NO_VTOR_CONFIG?[/quote]

The SES startup code will set the VTOR register to match the start address of the application unless NO_VTOR_CONFIG is set. VTOR needs to be =0 when working with the Softdevice to ensure interrupts are received by the MBR/Softdevice and not just the application.

Another thing to keep in mind is that the MBR/Softdevice uses the first to words of RAM even if the application is not enabling the Softdevice. This means that you should reserve the first 8 bytes of RAM in your application by setting the RAM start address to 0x20000008 or more. E.g.,

(Note: RAM_SIZE must not exceed total RAM on device - 8).

Best regards,

Vidar