Three NRF5SDK DFU questions

[snoopy20]

1. After DFU has successfully completed the watchdog fires. I know this because my App picks it up from the register, however I'd like to use this bit to indicate a potential software quality issue. So how to change the DFU behaviour so it does a system reset instead?

2. I need my App to change behaviour when being booted from a successful DFU update. Can I merely use sd_power_gpregret_set(1, some_value) attached to the 'NRF_DFU_EVT_DFU_COMPLETED'   event?

3. Curiosity question, if I package a bootloader in with the update how does the DFU implement it given the space, will it write the new bootloader to the App space, set config, switch to it, copy the bootloader into the old bootloader space, set config, then proceed with the App write? Same process for softdevice update?

Thanks!

[Vidar Berg]

Hello,

1. After DFU has successfully completed the watchdog fires. I know this because my App picks it up from the register, however I'd like to use this bit to indicate a potential software quality issue. So how to change the DFU behaviour so it does a system reset instead?

Which SDK version is your bootloader based on? The bootloader checks if the WD is enabled at boot and should start periodic feeding to prevent it from timing out during the DFU process.

2. I need my App to change behaviour when being booted from a successful DFU update. Can I merely use sd_power_gpregret_set(1, some_value) attached to the 'NRF_DFU_EVT_DFU_COMPLETED'   event?

Yes, I do not foresee any problems with this approach as long as the value is different from the existing DFU flags used by the bootloader (BOOTLOADER_DFU_*).

3. Curiosity question, if I package a bootloader in with the update how does the DFU implement it given the space, will it write the new bootloader to the App space, set config, switch to it, copy the bootloader into the old bootloader space, set config, then proceed with the App write? Same process for softdevice update?

Yes, it’s the same as with a softdevice and application update. The update is performed in two rounds with two different init commands. First, the bootloader is uploaded and activated, then the application as a separate update.

https://docs.nordicsemi.com/bundle/sdk_nrf5_v17.1.0/page/lib_bootloader_dfu_banks.html 

Best regards,

Vidar

[snoopy20]

1. nRF5 SDK v16.0.0 I believe. The watchdog is always enabled by the App with a 500ms timeout and the App always inits the DFU reset. I can see that watchdog is retained on soft reset so I figure the SDK code looks at whether it's enabled and feeds it values. I can't see any other config in the SDK DFU code and given it's working it must be feeding within the 500ms, at least until after success.

2. I was specifically intending to use gpregret2 to avoid conflict with softdevice codes. I can see the first bit is used to disable App CRC checking. Hopefully I can just choose another bit.

3. Perfect diagrams, it is as I expected. Thank you!

[snoopy20]

My softdevice is s112 v7.20 which didn't become supported until SDK v17.0.2. I missed it as there's no complaining and no obvious issue.

[Vidar Berg]

Thanks for confirming the SDK version. There should not be any problems with the WD feeding mechanism in this version, but 500 ms is a relatively short timeout for the WD. Does the app feed the WD at the beginning of main or after the initialization is complete? 

[snoopy20]

My bad I double checked and it's 2 seconds. It feeds it quickly at the beginning. Are you thinking there's a race between whatever occurs at the end of the success and entering the App, which causes a watchdog reset, the DFU then restarts with watchdog disabled (since it hasn't entered by App) and now can complete?

[snoopy20]

Sorted!