Booting application from custom bootloader

[AntonHellbe]

Hi,

I'm currently developing a custom bootloader for DFU, using I2C.

The bootloader is based upon the secure UART bootloader for nRF52832. Transferring and writing the image works fine, I receive the entire image and write it at the start address 0x26000 (Softdevice is present). To boot the application I currently use nrf_bootloader_app_start(), however that doesn't seem to want to start the application. Do I need to change the start address for the nrf_bootloader_app_start? Currently it uses 0x00001000 (MBR).

Edit: An additional question, is it possible to flash the nRF52832 using a Motorola Srecord hex file? I've tried looking for any documentation of which .hex files that nrfjprog accepts but cannot find any.

HW: nRF52832 PCA10040 devkit

SDK: v15.3

SD: 6.1.1

[HuanVH]

You can see in this post

If you using softdevice, you must start at softdevice address: 0x1000

[Vidar Berg]

0x1000 is the correct address. Have you confirmed that the program reaches the jump_to_addr routine?

AntonHellbe said:

Edit: An additional question, is it possible to flash the nRF52832 using a Motorola Srecord hex file? I've tried looking for any documentation of which .hex files that nrfjprog accepts but cannot find any.

nrfjprog supports intelHex only, but Jlink commander seems to support it. 

[AntonHellbe]

Hi,

I found the issue, after reading some of the memory addresses starting at 0x26000 I could see that the data written to flash was not correct. After correcting the memory writes the Softdevice now boots the application correctly.

Regarding booting the application after a successful image transfer. Currently I receive the image, write it to flash. When the entire Image received I calculate CRC from what's written to the memory and compare it to the CRC I receive in the start of the image transfer. If the CRC is correct, I clear the gpregret and and perform a NVIC_Systemreset() so that the bootloader will boot the new image.

Is that a sufficient solution? - Clearing the GPREGRET reg and performing a NVIC_Systemreset() when booting up a new image written to flash. Or is there something else that I should to before booting up the new Image?

Br,
Anton

[Vidar Berg]

Hei Anton,

AntonHellbe said:

Is that a sufficient solution? - Clearing the GPREGRET reg and performing a NVIC_Systemreset() when booting up a new image written to flash. Or is there something else that I should to before booting up the new Image?

Can the bootloader boot an app that has not been fully updated if the GREPREGRET flag is cleared due to an unexpected power loss,etc, or do you also have a "bootloader settings" page in flash like the SDK bootloader has?   

[AntonHellbe]

Hei hei Vidar,

No I have not implemented a bootloader settings page, so yes, if there is an unexpected power loss during the transmission the bootloader would attempt to boot that application.

Are there any information create/use the settings page for "custom" behaviour?

[Vidar Berg]

I don't think you have to have to include a settings page. An alternative is to always calculate the app CRC on boot. If the check fails, you can just let the bootloader fall back to DFU mode.

I guess the question is then where it's best to store the CRC. I encountered a fairly similar project in a project where I was trying to add DFU support without having a dedicated bootloader. I ended up appending a 32 bit CRC at the end of the app image to avoid having to allocate a settings page in flash. 

ble_app_beacon_w_dfu.zip

[AntonHellbe]

That's a nifty solution, something I will most likely use.

One thing I've noticed is that in order to boot the application (after a succesful image transfer) I always have to reset an additional time on the devkit before the application boots. It seems like the NVIC_Systemreset() is not doing the trick after the image is flashed.

Any thoughts what could be the cause?

[Vidar Berg]

Do you know what the device is doing when it doesn't boot the app? Maybe it went back to DFU mode inside the bootloader, or got stuck in a fault handler? You can run "nrfjprog --readregs" to find out where the program is running at.

[AntonHellbe]

I've been trying to find out what's going on but it seems like it might hit a fault handler?

After receiving and image, verifying its CRC and writing it to memory the nRF52832 goes unresponsive for about 30-45 seconds. When I try to read the registers nrfjprog only returns:

ERROR: JLinkARM DLL reported an error. Try again. If error condition                                              
ERROR: persists, run the same command again with argument --log, contact Nordic                                   
ERROR: Semiconductor and provide the generated log.log file to them. 

After 30 seconds or so I can read the registers

R0:   0x01000001
R1:   0x40020518
R2:   0xE000E100
R3:   0x20002585
R4:   0x200000C0
R5:   0x00000000
R6:   0xE000E000
R7:   0x00000000
R8:   0x00000000
R9:   0x00000000
R10:  0x20000000
R11:  0x00000000
R12:  0x00000000
SP:   0x2000FF38
LR:   0x00015CCD
PC:   0x00015CCE
xPSR: 0x61000000
MSP:  0x2000FF38
PSP:  0x00000000

And the application is running.

Edit: Seems like it can take up to a minute or two. During this period I cannot connect to the nRF52832 using JLinkExe and I get disconnected when I boot the image:

****** Error: Communication timed out: Requested 12 bytes, received 0 bytes !