What happens after the final execute op code of the DFU?

[PF-JohnF]

I've been digging through the DFU in order to reduce it's power and I've come across 3 high power states.

1) The first is during initialization of the DFU. It happens on the first "execute" op code 0x04, where the public key and private key are verified. It takes around 600uC of charge, and around 125 milliseconds to verify the SHA256 hashes.

2) After all of the packets have been transmitted and during the final execute op code, there is a CRC check on the application that was just transmitted. The amount of charge and time it takes to process the CRC is variable and based on how large the application transmitted was.

3) Something right before the device reboots. I haven't been able to figure out where the continues execution after the final CRC check.

I have tried re-configuring the sdk_config file in order to bypass these checks, but the SHA256 verification is required. The CRC check at the end could most likely be removed since a periodic CRC check happens during the DFU transfer.

Could somebody point me where the code continues execution? I'm not sure if it's a reset state I should be worried about or if there's some data being moved around that is required for the application to boot.

Thanks ahead of time.

[Amanda Hsieh]

Hi John, 

Could you try to generate the package with  --app-boot-validation NO_VALIDATION  (skip CRC) for comparison? Does it help?

-Amanda H.

[PF-JohnF]

Thank you for your response

I used the command

nrfutil.exe pkg generate --app-boot-validation NO_VALIDATION --hw-version 52 --sd-req 0x101 --application-version 0xff --application APP2.hex --key-file ../priv.pem APP2.zip

to generate a .zip file without validation, and kept the old .zip file with validation and compared the power consumption of the two.

Here's the power consumption after the application hex file has finished transmitting:

With validation:

Without validation:

The first high power state in this graph is the crc/validation check. The power consumed without validation is about half of the power consumed when using validation during the validation step.

By commenting out or removing the validation check from the postvalidate function in nrf_dfu_validation, power usage is reduced even further.

I'm confused what happens after the crc check though, and I'm having a tough time to follow the execution path of the code after it leaves nrf_dfu_req_handler. I'm not sure if there is a lot of data being copied to another bank or is it possible that the high power is just caused when the device is reset, or maybe even something else entirely?

[Amanda Hsieh]

The RTT log from using _debug example bootloader project can help. Also, see the Device Firmware Update process doc.  

-Amanda H.