Accept Firmware Upgarde via callback registration.

[Simon]

Hi,

I am currently using "mgmt_callback_register() " to subscribe to MGMT_EVT_OP_IMG_MGMT_DFU_CHUNK event to prevent firmware update in some cases by returning MGMT_ERR_EACCESSDENIED.

This works fine for prventing new fw images to be sent and therefore terminates dfu process. I noticed that if you want to revert to the previous version then image is not send as already exist inside flash. In this case app does not receive any callback and dfu process can't be terminated. 

Is there any other event to which app can subscibe before actual dfu process is started?

Thanks,

Simon

[Sigurd Hellesvik]

Hi,

For us to help you with this in the best possible way, please list the following information:

• SDK Version
• Development Kit Version
• Which sample do you use, if any?

Regards,
Sigurd Hellesvik

[Simon]

Hi,

SoC: nrf52840
Environment: nRF Connect SDK v2.4.1

I use custom board with custom software.

Regards,

Simon

[Sigurd Hellesvik]

I noticed that if you want to revert to the previous version

Which command is used to do this?

[Simon]

Just normal dfu process used from nRF Connect or Device Manager app and with fw image which was loaded before current one

[Sigurd Hellesvik]

So when you say "revert", you mean that you do normal DFU, but decrease the version of the app?

I am asking, since MCUboot has a concept named revert also. When an image is tagget as "test", it becomes automatically tagged "revert" after the swap, so it will go back if it was not confirmed before a reset.

[Simon]

Thanks for the information. I wasn't aware of the revert functionality. Actually what I want to ask is how the user can accept or reject the firmware upgrade on the device (via button or it is done automatically based on the device status). Is there any preferred way to do this? Is registering to MGMT_EVT_OP_IMG_MGMT_DFU_CHUNK event correct way to reject dfu or is there any other way to do it even before actual image transfer has been started?

[Sigurd Hellesvik]

If I were you, I think I would approach this from another angle.
Let's see if I understand this correctly.

You do DFU, and you want to be able to accept or reject DFU. (Right?)

You have two slots, and the new update is saved in mcuboot_secondary when downloaded. I do not see any reason to why you would decide anything about DFU before it is finished downloaded. Let me know if you have any reasons here?

I would download the full new firmware into the secondary slot. Then when you want to update the device, you can tag the new firmware as "test". This will swap back on next reset unless you tag it with "test" over the DFU protocol (e.g. BLE) or call boot_write_img_confirmed().

If you missed context to understand what I say, see the new course at https://academy.nordicsemi.com/courses/nrf-connect-sdk-intermediate/.

Will this solution work for you, or have I missed anything?