nRF51822: secure DFU over BLE

RE: nRF51822: secure DFU over BLE

Hung Bui — Wed, 20 Apr 2022 13:09:02 GMT

Hi Bojan,

Have you tried to test without the programmer/debugger connected ?

After the DFU process is finished the bootloader will reset the chip in this function: on_dfu_complete()

The function is called in the flash call back after the bootloader setting write is finished. See this call
// Store the settings to flash and reset after that
if( nrf_dfu_settings_write(on_dfu_complete) != NRF_SUCCESS)

In dfu_reg_handling.c file.

Please try to test using some logging to see why it hang and couldn't reset.

RE: nRF51822: secure DFU over BLE

bojan — Wed, 20 Apr 2022 12:25:56 GMT

Hello, Hung Bui.

We disabled checking the state of P0.20 pin in nrf_dfu_enter_check() function. It seems that this had a positive impact and we were able to go one step further.

What is happening now is that our custom board does not start with the new application code until we press the Reset button on Programmer window.

On the other hand, when we use the nRF51DK instead of our custom board and apply the very same set of steps, the new application starts running properly after we transfer the DFU package over BLE.

Do you have any idea about what might be the issue?

Here is the part of our custom board schematic that contains nRF51 and program/debug interface:

Sincerely,

Bojan.

RE: nRF51822: secure DFU over BLE

Hung Bui — Tue, 19 Apr 2022 13:35:14 GMT

Hi Bojan,
In that case you can just remove the check:

if (nrf_gpio_pin_read(BOOTLOADER_BUTTON) == 0)
{
return true;
}

in nrf_dfu_enter_check() function to not having the button involved.

Or you can declare your own nrf_dfu_enter_check() to overwrite it, since the original nrf_dfu_enter_check() function in nrf_dfu.c is defined as WEAK.

RE: nRF51822: secure DFU over BLE

bojan — Tue, 19 Apr 2022 12:47:07 GMT

Hello, Hung Bui.

Thanks for your feedback.

We are using our custom-designed board with nRF51822 SoC on it. Pin P0.20 is physically connected to the interrupt output of the accelerometer. We don't have any external pull-up resistor that will tie the P0.20 to VDD.

Is something like this necessary?

Can we configure P0.20 GPIO as input with the internal pull-up resistor? We are interested in buttonless DFU in our use case.

Sincerely,

Bojan.

RE: nRF51822: secure DFU over BLE

Hung Bui — Tue, 19 Apr 2022 12:34:02 GMT

Hi Bojan,

Could you check if you have any error log on the device when you do DFU update ?

Which hardware did you test your bootloader on ? Please be note that by default the DFU bootloader is always entered if a button (BOOTLOADER_BUTTON = BSP_BUTTON_3 = Pin P0.20) is pressed (connect to ground). Check function nrf_dfu_enter_check(). I suspect that the button was not connected to VDD and causing the bootloader to enter DFU all the time.

For testing I would suggest to try doing DFU a very simple project, for example the \peripheral\blinky\pca10028\s130

I don't think merge the bootloader and application and softdevice would make any different here.

I would suggest to test using the debug version of the bootloader. With that you can step into the code and check why the bootloader doesn't want to jump to the application. Please focus on nrf_dfu_init() function in nrf_dfu.c , in that function you can find out why the bootloader stay in DFU mode instead of jumping application, focus on nrf_dfu_enter_check() and nrf_dfu_app_is_valid()