Bootloader Jump to Main application crashes after modifying RAM_START address from 0x20002300 to anything else

[rishi]

Hi there...

I am using :

Device :Custom board using nrf52840 (fanstel module BT840)

SDK : nRF5_SDK_17.0.2

SoftDevice : S140 7.2.0

In order to add DFU capability on our product, I started with pca10056_usb_debug secure bootloader, first tested it on dev board (PCA10056) with ble blinky application everything works fine as expected. Then ported usb bootloader to our custom board and updating ble blinky application  works ok.

When i try to flash our real application, DFU process finishes successfully after BL reboots and tries to jump to our real application there it crashes (it never enters the main function of application).

The only difference in ble blinky and our real application is the application size and RAM_START setting which is 0x20002300 in blinky app but 0x20002bf0 in our real application.

I am wondering if i need to modify some setting in boot loader in order to compensate this RAM_START modification?

But my understanding is the way control flows is as follows :

If BL is present :

MBR->BL>SoftDevice->Application.

else if there is no BL:

MBR>SoftDevice->Application.

So basically Softdevice knows how to jump to main application as i can run/debug my real application without BL in the picture.

And as i understand the BL functioning it always calls the Softdevice (0x1000) and then its SD responsibility to jump to main application.

So why this RAM_START is an issue for Bootloader?

Will appreciate any help/ pointers to documentation which clarify this question...

Thanks a lot!

[rishi]

Yes i am coding the Boot loader and the application, i do not need to try and error i know for sure my application's start address.

My real question is where and how to modify the boot loader so that it can jump to my application correctly.

Application crashes after control is passed from jump_to_addr() function in nrf_bootloader_app_start_final.c

[Henry_Chou]

The boot loader should be merged SD and your application code. Howerver, you may take reference with the Nordic SDK DFU code. \nRF5_SDK_17.0.2_d674dde\examples\dfu\secure_bootloader

[Vidar Berg]

Hello,

Thanks for the detailed report. It's interesting that it works fine with the BLE blinky app, but not with your custom app. I don't see how it could be related to the RAM_START address either.

When i try to flash our real application, DFU process finishes successfully after BL reboots and tries to jump to our real application there it crashes (it never enters the main function of application).

Are you able to take a screenshot of the call stack and cpu registers when this crash happens? I'm hoping it will show where the program ends up after the call to jump_to_addr() is made. Also, as a test, if you could try  comment the " __set_MSP(new_msp);" line in jump_to_addr() and see if it still crashes (in case the generated assembly loads the "addr" from stack memory instead of R1).

I am wondering if i need to modify some setting in boot loader in order to compensate this RAM_START modification?

No, the bootloader is only responsible for forwarding execution to the application's reset handler. The reset handler will then re-initalize the RAM above RAM_START.

Best regards,

Vidar