Secure Serial DFU SDK13 – DFU post validate complete indication

[rct42]

Greetings,

I have an application where the DFU of a NRF52 is performed by another microcontroller via a serial port. Once the DFU is complete, the microcontroller turns off the entire system (including the NRF52). The issue I am encountering is associated with the steps performed by the bootloader after the complete application binary has been received.

I’ve noticed that the “nrf_dfu_postvalidate” step can take up to 10s. In the past I’ve waited until I have received a ping response back from the bootloader. This gave me some success. I have also tried a simple blocking delay of 15s after the DFU, but I do not like this approach. If the main microcontroller turns off the NRF52 before the DFU post-validate step is complete, the next time the NRF52 starts it stays in the bootloader mode. This means I have to perform the DFU process twice each time I wish to upgrade the NRF52 firmware.

Is there a way with the existing implemented SLIP OP codes to get confirmation from the bootloader that the new application has been validated and set to run next time it boots?

Note: I’m using SDK13 and the secure serial bootloader with slight modifications (UART without flow control, different pin mappings, WDT reset during DFU… etc). The application image I am updating is also large (120kB).

[Hung Bui]

Hi,

If you have a look here:

The Response Execute Success will be sent after the nrf_dfu_postvalidate() step to check if the image's hash matches with the hash in the init packet but not after the bootloader setting is written to flash. So if you turn the power down right after that response, the bootloader setting won't be stored in flash.

But I don't think it would take 10 seconds for the bootloader setting to be written. If you do dual bank update, the 10 seconds could be the time it takes to erase bank 1 and copy bank 0 over.

Our suggestion is to send an extra UART response right before reset, inside on_dfu_complete(), but you need to put some delay (100ms for example) for the UART command to be send, before doing reset.

Another option is to send a UART packet when the new app is checked in nrf_dfu_app_is_valid(). But this mean you will print something on UART every time the nRF52 starts.

Regarding the response, you can re-send Response Execute Success and configure the DFU master to wait for 2 responses before power down. Or you can define a new opcode in side serial_dfu_op_code_t in nrf_serial_dfu.h

[Hung Bui]

You are correct, the CPU is freezing when flash operation is executing. So if there isn't enough buffer in UART peripheral, the ping command will be corrupted.

In normal use case, the DFU master shouldn't worry about the DFU slave anymore after the the post validation return success. The DFU slave supposed to be able to swap the (validated) image and start new application normally.

But I agree that it would be the best if we have a response after we replace the old image and verify the new image is valid. Or as you already have done, add a ping response in your app.