DFU question - I wonder whether there is a way that BLE knows the device is upgrade its software

[PingISTL]

Dear support

I tried DFU OTA example here recently and it works for me and have a question to ask.

My application is a central app and host by my main MCU via UART interface, I wonder when device firmware is being updated by OTA, is there a way the app knows before it enters boot mode, so it can tell main MCU a message about that ?

Thank you!

Ping 

[PingISTL]

Hi, Hieu

Thank you for reply and spend time on it, it is not an easy one, I understand.

Initially I thought it can tell by connected as a peripheral role as the advertising function is only added for DFU purpose, but then it is possible that it can be connected for echo or something else but not upgrading firmware.

If firmware had an unexpected reboot - not initiated by host MCU, then it is probably a reboot following a DFU OTA, but that can only be told after the DFU happened.

That is all I can think of, I am not familiar with more deep insight into the protocols.

Regards!

Ping

[Hieu]

Hi Ping,

I found a few API that can help you. You can click the link to go to the header file with full documentation. Further below are an example usage from me and the log from my test.

• In <NCS Root>\zephyr\subsys\mgmt\mcumgr\lib\cmd\os_mgmt
  void os_mgmt_register_reset_evt_cb(os_mgmt_on_reset_evt_cb cb);
  Unfortunately this API is only available from NCS v2.0.0. Are you working on the same NCS v1.9.1 from your previous ticket...?
  
  
• In <NCS Root>\zephyr\subsys\mgmt\mcumgr\lib\cmd\img_mgmt
  void img_mgmt_register_callbacks(const struct img_mgmt_dfu_callbacks_t *cb_struct);

void test_dfu_started_cb(void) { printk("%s\n", __func__); }
void test_dfu_stopped_cb(void) { printk("%s\n", __func__); }
void test_dfu_pending_cb(void) { printk("%s\n", __func__); }
void test_dfu_confirmed_cb(void) { printk("%s\n", __func__); }

const struct img_mgmt_dfu_callbacks_t test_img_mgmt_dfu_callbacks = {
    .dfu_started_cb = &test_dfu_started_cb,
    .dfu_stopped_cb = &test_dfu_stopped_cb,
    .dfu_pending_cb = &test_dfu_pending_cb,
    .dfu_confirmed_cb = &test_dfu_confirmed_cb
};

int test_os_mgmt_on_reset_evt_cb(void) {
    printk("%s\n", __func__);
    return 0;
}

void main(void)
{
    [...]
    
    printk("build time: " __DATE__ " " __TIME__ "\n");

    os_mgmt_register_group();
    os_mgmt_register_reset_evt_cb(&test_os_mgmt_on_reset_evt_cb);
    img_mgmt_register_group();
    img_mgmt_register_callbacks(&test_img_mgmt_dfu_callbacks);
    smp_bt_register();
    
    [...]
}

*** Booting Zephyr OS build v3.0.99-ncs1-1  ***
I: Starting bootloader
I: Primary image: magic=good, swap_type=0x2, copy_done=0x1, image_ok=0x1
I: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Boot source: none
I: Swap type: none
I: Bootloader chainload address offset: 0xc000
I: Jumping to the first image slot
▒*** Booting Zephyr OS build v3.0.99-ncs1-1  ***
Starting Nordic UART service example
build time: Sep 21 2022 18:40:24
test_dfu_started_cb
test_dfu_pending_cb
test_os_mgmt_on_reset_evt_cb
*** Booting Zephyr OS build v3.0.99-ncs1-1  ***
I: Starting bootloader
I: Primary image: magic=good, swap_type=0x2, copy_done=0x1, image_ok=0x1
I: Secondary image: magic=good, swap_type=0x2, copy_done=0x3, image_ok=0x3
I: Boot source: none
I: Swap type: test
I: Starting swap using move algorithm.
I: Bootloader chainload address offset: 0xc000
I: Jumping to the first image slot
*** Booting Zephyr OS build v3.0.99-ncs1-1  ***
Starting Nordic UART service example
build timex: Sep 21 2022 17:18:35

As of now I haven't seen any API to interfere with the DFU process as suggested in this Q&A yet. However, is it enough for your current requirement yet?

Side note, I am out of office tomorrow, so unfortunately the earliest I can follow up will be Friday.

Best regards,

Hieu

[PingISTL]

Hi, Hieu

Thank you for your contribution!

The solution works for me - exactly what I need.

1. I had to upgrade my SDK to v2.1.0 to use first feature, which took a while as code is not backwards compatible, don't understand why it is so hard to migrant from 1 version to another.

2. The second call back works straight away.

3. BTW - my custom board overlay file had to modify too to work on it.

Thank again.

Ping

[Hieu]

Hi Ping,

Glad to hear things worked for you. I have not performed an SDK upgrade myself, so I don't know the first-hand experience. I think you already know, but just in case, there is a guide available here: https://developer.nordicsemi.com/nRF_Connect_SDK/doc/2.0.0/nrf/migration/migration_guide_1.x_to_2.x.html

It is weird that you have to update overlay file for this, since we didn't really touch any hardware resources. 
If you don't mind, what did you have to change?

Best regards,

Hieu

[PingISTL]

Hi, Hieu

Thanks for the link, I will read it  although it is better read before. It seems like a big change.

I had to change the uart1 pin like the new pinctrl feature format like below instead of pin number for the overlay file. Had to manually create new custom board file too. 

 

&uart1 {
    status = "okay";
    pinctrl-0 = <&uart1_default>;
    pinctrl-1 = <&uart1_sleep>;
    pinctrl-names = "default", "sleep";
}; 

Also tested some DFU OTA this morning, and found that:

1. "started call back" is only called when start  downloading a new version, if image is already there, it won't downloading, right? 

2. Never " stopped call back " happen.

3. Sometime, "confirmed call back " is not called.

Anyway, it is good enough for me to use and thank you again for your hard work!

Regards!

Ping

[Hieu]

Hi Ping,

Ah, so the change in overlay file is for upgrading the SDK, not for setting up the img_mgmt callbacks, right? That would make sense.

Your observation is the same as mine. If you wish to see the other callback in action, try playing with DFU using the Advanced option on the app nRF Connect Device Manager.

The Started callback works exactly as you understand it. Only for the initial trigger of an image upload. If the upload is paused and resumed, the callback is not called again.

I haven't investigated this thoroughly, but if I understand correctly, the Stopped callback is only called when firmware upload or erase encounters an error. You could check more by looking up where img_mgmt_dfu_stopped() is called.

The Confirmed callback is only called when the new firmware is Confirmed during its Test boot.

See also: MCUmgr — Zephyr Project Documentation (nordicsemi.com)

---

By the way, just for completeness's sake, there is one more callback API of interest. This one is called before any upload happen:

In <NCS Root>\zephyr\subsys\mgmt\mcumgr\lib\cmd\img_mgmt
void img_mgmt_register_callbacks(const struct img_mgmt_dfu_callbacks_t *cb_struct);

---

I have suggested my previous reply as the answer. If you can verify it, that would be great, or I will do so in a few days.

Best regards,

Hieu