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

[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