Secure Bootloader for DFU support on nRF52805

[swanav]

I am developing a firmware for the nRF52805 SoC with a nRF52 DK. I want to implement the DFU support on the same. The secure bootloader example in examples\dfu\secure_bootloader for the pca10040e_s112_ble works properly and I am able to test out the DFU on the nRF52 DK. But I am not able to figure out what changes need to be done to make it to work on the nRF52805.

OS:

   Windows 10

SW Version: 

   nRF SDK Version: 17.0.2 (d674dde)

[Hung Bui]

Hi Swanav, 

I don't see any difference between the nRF52810 (that supported by pca10040e_s112_ble ) and the nRF52805 related to the bootloader project (they have the same flash and RAM size). You should be able to use the exact same code setting for the nRF52805. 
You must of course change the boards.h to include your own .h file that defines the GPIOs according to your board (equivalent to pca10040.h)

[swanav]

Hi Hung!

Thanks for your response.

I understand that the GPIOs indeed need to be mapped according to my board. But that is also something that I have already taken care of.

I will share my observations in the difference of behavior between the 2 setups, and you could shed some light on what I am missing.

Flashing my application on the nRF52 DK as well as my custom board with nRF52805 (with the GPIOs remapped), give the same behavior. Both the devices behave identically. There is a single GPIO on my board to indicate operations, that is also working properly. I did not even need to make any changes for the nRF52805. The binary for pca10040e (nRF52810 emulated) seems to be working without any changes needed.

This confirms 3 things for me. My schematic is correct, the SoC is not dead and I can flash binaries onto it.

Now coming to the Secure Bootloader.

I am able to flash the pca10040e project on the nRF52 DK. The SoC boots into the bootloader and advertises a Peripheral with name DfuTarg. I am able to connect to it and flash a binary prepared with the steps given here. The SoC even boots into the new firmware, meaning my DFU worked successfully.

When I flash the same project to my board with the nRF52805 SoC, the device does not seem to be doing anything at all. No Advertisement. I have a single GPIO on my Board, I try switching it on in the firmware, does not seem to work either.  

[Hung Bui]

Hi Swanav, 

The bootloader is a little special application that it located at the bottom end of the flash. For the bootloader to execute it requires the UICR to be written. So before testing please make sure you do an nrfjprog --eraseall to erase the chip. I assume you flashed the softdevice before you flash the bootloader ? 

I would suggest to test with the debug version of the bootloader, compile it with no optimization, and try stepping to the code to debug it. Please check if you can jump to main() in the bootloader. 

[swanav]

Hi Hung!

So, I did the following steps:

> nrfjprog --eraseall

> nrfjprog.exe --family NRF52 --program s112_nrf52_7.2.0_softdevice.hex --chiperase --verify

> nrfjprog --family NRF52 --program .\secure_bootloader_ble_s112_pca10040e.elf --verify

Parsing hex file.
ERROR: The file specified is not a valid hex file, has data outside valid areas
ERROR: or does not have data in valid areas.

So, then I flashed the bootloader from within the SES.

No activity again. The device does not advertise DfuTarg.

I tried preparing a debug build of the bootloader, but received a lot of errors.

[Hung Bui]

Hi, 
You should flash the .hex file, not the .elf file.

The error you receive when building the bootloader without optimization is because the size of the bootloader is large than the allocated size for it. You need to move the start address of the bootloader down, and increase the flash size in the Project setting. 
If you use the _debug version of the bootloader you should be able to build with the optimization level 0. In the example we already move the bootloader location down in flash, giving it more space. 

[swanav]

I managed to build the _debug version of the bootloader with Optimization Level Set to 0. 

Running the bootloader in debugging mode on both the boards, led me to this discovery.

The behavior branches here at

nrf_dfu_transport.c:60  ret_val = trans->init_func(observer);

This statement returns on the nRF52DK with a ret_val == NRF_SUCCESS, while on the nRF52805, this does not return at all. The debugger seems to crash here.

[Hung Bui]

Hi Swanav, 

By default this ret_val = trans->init_func(observer); will jump to the function ble_dfu_transport_init() as it's declared by this code in the nrf_dfu_ble.c: 

DFU_TRANSPORT_REGISTER(nrf_dfu_transport_t const ble_dfu_transport) =
{
.init_func = ble_dfu_transport_init,
.close_func = ble_dfu_transport_close,
};

Could you try adding a breakpoint inside ble_dfu_transport_init() ? 
I assume you have flash S122 on the nRF52805 board  ?