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

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 

  • Hi Ping,

    Just want to let you know that I got on the case. I will have to spend some more time on this, sorry.

    I did spend quite some time looking into the APIs of SMP services and GATT, but there don't seem to be anything there that can serve your purpose.

    Best regards,

    Hieu

  • 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

  • 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.

    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

  • 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

  • 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

Related