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]

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 !

[AntonHellbe]

I hit a fault handler when I tried to uninit fsstorage, resolved by waiting until it was not busy anymore. Now the app boots instantly :).

[AntonHellbe]

Hi,

Not sure if I understand the code correctly, but does the CODE_SIZE define keep track of the length/size of the application? So that you know where the CRC is located in the memory.

/ Anton

[Vidar Berg]

Hi,

Yes that's correct, CODE_SIZE gives the application size and is used to locate the CRC, which is appended at the end.

[AntonHellbe]

I tested it out and it works good, cheers for all the help Vidar.

/ Anton

[Vidar Berg]

Excellent! Thanks for the update.