BLE Secure bootloader SD clock issues

[pjboudewijns]

Hallo All :-)

As an enthousiast hobbyist I've developed a custom board around an nRF52832-CIAA. When I started testing with a BLE secure bootloader from the SDK16 examples, it all worked flawless on my PCA10040 evaluation board. On my own board however the bootloader did not start at all.

After extensive testing and debugging I found the code failed upon enabling the SoftDevice (I use 6.1.1). This was in nrf_sdh.c in the function call :

ret_code = sd_softdevice_enable(&clock_lf_config, app_error_fault_handler);

Using yet another demo board I found that removing the 32.768 kHz LF crystal caused exactly the same error as seen on my own design. And yes, indeed is this crystal NOT present on my own board. So, no problem I thought. Simply change the clock configuration .........

Sadly I found that whatever I do, the SoftDevice will only start when NRF_SDH_CLOCK_LF_SRC is set to 1 (= XTAL) AND the 32.768 kHz crystal is present.

I've tried every combination between hardware and sdk_ config.h configuration. Defining a clock in the board header file also yields no result. In the SDK header that describes the function for enabling the SoftDevice I read that passing NULL as argument for the clock source would instruct the SoftDevice to use the RC clock with correct settings for calibration interval and temperature drift. Sorry to say,  this also failed.

So, HELP! Anyone got an idea?

Peter

Note : After I posted this question I've continued my search. Now at last the secure bootloader comes to life. In the file nrf_sdm.h (line 310) the comment states that the NULL 'clock argument' passed on calling sd_softdevice_enable() forces the softdevice to use the internal RC clock for LF. So I tried this once more :

ret_code = sd_softdevice_enable(&clock_lf_cfg, app_error_fault_handler);  -> changed into  ret_code = sd_softdevice_enable(NULL, app_error_fault_handler);

Leaving the NRF_SDH_CLOCK_LF_SRC in sdk_config.h at 1 (selecting the XTAL).

Now I sometimes get the DfuTarg when scanning with the nRFConnect App on my phone :-) But I'm not satisfied yet. I want to ALWAYS get the DfuTarg after a device reset (with no valid application that is).

I also tried a DFU_OTA. After a few disconnects I succeeded once. It is far from stable at the moment .....

[bjorn-spockeli]

Hi Peter, 

Does your custom board have the external 32.768 kHz crystal?  If it does not, then you need to configure the SoftDevice to use the internal RC oscillator by setting the following defines in the sdk_config.h file in both the bootloader project and in your application project. 

#define NRF_SDH_CLOCK_LF_SRC 0

#define NRF_SDH_CLOCK_LF_RC_CTIV 16

#define NRF_SDH_CLOCK_LF_RC_TEMP_CTIV 2

#define NRF_SDH_CLOCK_LF_ACCURACY 1 

Best regards

Bjørn

[pjboudewijns]

Hi Bjorn,

No, my own design does not have a 32.768 kHz crystal. So I already experimented with the settings you mentioned. Right now my bootloader is functional, but is looks like the changed setting has a great influence on the BLE functionality. When I start the device without a valid application it sometimes takes almost 30 seconds before the device is 'found' by the app on my phone. Sometimes it cant be found at all.

When found, I can perform an OTA DFU with my own application based on the BUTTONLESS_DFU example. So I've made a huge leap forward. But my only concern is the seemingly 'unstable' behaviour on BLE.

[bjorn-spockeli]

The LFCLK setting should not affect the "discoverablity" of the device. Its the advertisment interval that will determine how quickly a device is "found" by a BLE Central that is scanning. WHich mobile app are you using to scan for BLE devices?

Best regards

Bjørn

[pjboudewijns]

Hi Bjorn,

You are so right! I am using the nRF Connect app. But to my shame I discovered I was still using an RSSI filter that was critical. So most of the time the RF signal from my board didn't exceed the threshold. And thus, the device did not appear in the app leading me to conclude it was not transmitting. Stupid mistake. So now the bootloader and my own buttonless DFU application both work super!

Thanks for your support. Nordic rocks :-)

PeTer

[bjorn-spockeli]

Hi Peter, 

Aha, that explains it. Anyways, happy to hear that things are working as they should!

Happy to help

Best regards

Bjørn