This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

mesh DFU failure scenario

Hi,

I manged to successfully run the mesh DFU example, however i noticed one unusual thing. I was expecting device to revert to old version of firmware, if  in case the update breaks for some reason(i.e wrong application version, key or sudden abort during update) but in reality i found that devices stays in DFU mode. How ever if next update is successful they run the new firmware. 

Is this normal ? why device is not reverting back to old firmware if new one is not successful ?

Parents
  • Hi,

    Sorry for the late reply. The mesh DFU example should run what is called as side-by-side DFU, it transfers the new firmware in the background while the application is running and it will not flash the new application before it is ready, so there isn't really a DFU mode. Have you check the DFU quick starting guide and made sure you have followed all the steps here? https://www.nordicsemi.com/DocLib/Content/SDK_Doc/Mesh_SDK/v3-1-0/md_doc_getting_started_dfu_quick_start

    Best Regards,

    Marjeris

  • Hello,
    I did follow all the steps, otherwise i could not successfully transfer firmware image. It seemed to me the device in DFU mode because in failure scenario( Lets say i suddenly stopped dfu transfer) it was not reverting back to previously running application, instead two lights were on and in next attempt it successfully updated firmware.

    I will try again, and meanwhile is it possible to test for u?

  • Hi,

    Sorry for the late reply. I have tested the mesh DFU example now. If you are testing the example out of the box, the old firmware running in both DKs will be the mesh dfu application, that's the image running before and during the dfu process. The dfu mesh application turned on LED1 and LED3 when the mesh dfu event started. If you see inside the code the leds will not turn off before the NRF_MESH_EVT_DFU_END event happens. So I think it makes sense that you still see the two leds on when a failure happens...

            case NRF_MESH_EVT_DFU_START:
                hal_led_mask_set(BSP_LED_0_MASK | BSP_LED_2_MASK, true);
                break;
    
            case NRF_MESH_EVT_DFU_END:
                hal_led_mask_set(LEDS_MASK, false); /* Turn off all LEDs */
                hal_led_mask_set(BSP_LED_0_MASK | BSP_LED_1_MASK, true); /* Yellow */
                break;

    I think this could have been better documented, so thank you for pointing this out for us!

    If I misunderstood and you are running you own firmware before doing the dfu, please let me know.

    Best Regards,

    Marjeris

Reply
  • Hi,

    Sorry for the late reply. I have tested the mesh DFU example now. If you are testing the example out of the box, the old firmware running in both DKs will be the mesh dfu application, that's the image running before and during the dfu process. The dfu mesh application turned on LED1 and LED3 when the mesh dfu event started. If you see inside the code the leds will not turn off before the NRF_MESH_EVT_DFU_END event happens. So I think it makes sense that you still see the two leds on when a failure happens...

            case NRF_MESH_EVT_DFU_START:
                hal_led_mask_set(BSP_LED_0_MASK | BSP_LED_2_MASK, true);
                break;
    
            case NRF_MESH_EVT_DFU_END:
                hal_led_mask_set(LEDS_MASK, false); /* Turn off all LEDs */
                hal_led_mask_set(BSP_LED_0_MASK | BSP_LED_1_MASK, true); /* Yellow */
                break;

    I think this could have been better documented, so thank you for pointing this out for us!

    If I misunderstood and you are running you own firmware before doing the dfu, please let me know.

    Best Regards,

    Marjeris

Children
No Data
Related