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.  

[swanav]

Hi Hung!

I have flashed S112 on the nRF52805 board. 

Managed to reach ble_dfu_transport_init(). Found that nrf_sdh_enable_request() does not return. Digging a bit deeper, found that this call does not return.

nrf_sdh.c:214 ret_code = sd_softdevice_enable(&clock_lf_cfg, app_error_fault_handler);

I feel that this may be due to some issue on the softdevice, but what stumps me is how my application is working on the same board?

[Hung Bui]

I think I found what could be wrong here. Do you have an external 32kHz crystal on your board ? 
If not, you would need to configure the NRF_SDH_CLOCK_LF_SRC to 0 (NRF_CLOCK_LF_SRC_RC) in sdk_config.h 

It's the most common reason the sd_softdevice_enable() doesn't return. 

[swanav]

Changing NRF_SDH_CLOCK_LF_SRC to 0 helped. sd_softdevice_enable() returns now, but with a return value of NRF_ERROR_INVALID_PARAM (7).

[swanav]

Hi Hung!

Changing these additional macros seems to have made it work. I can see the advertisement DfuTarg now!

#define NRF_SDH_CLOCK_LF_RC_CTIV 10

#define NRF_SDH_CLOCK_LF_RC_TEMP_CTIV 2

#define NRF_SDH_CLOCK_LF_ACCURACY 1

I will run some more tests and let you know if it worked!

[Hung Bui]

Please also configure other LFCLK parameter. If you select NRF_SDH_CLOCK_LF_SRC  you need to configure other parameter, same as in your application (if the application run on your custom board)
Please try :

NRF_SDH_CLOCK_LF_RC_CTIV= 5

NRF_SDH_CLOCK_LF_RC_TEMP_CTIV = 0 

NRF_SDH_CLOCK_LF_ACCURACY = 1

 

[swanav]

Hi Hung!

It does work after these changes!

Thank you so much for all your help!