LED array indication while dfu process in MCU boot

I am working on a project where my hardware includes an array of LEDs. I want to run an LED pattern on the array during the DFU process. I have tried to find a solution for this and found that there is an MCUboot indication LED macro available in Zephyr. However, I am unsure how to implement this on an array of LEDs.

  • In case you don't want to modify sdk code, I used MCUmgr callbacks to implement something similar to what you describe:
    https://docs.zephyrproject.org/latest/services/device_mgmt/mcumgr_callbacks.html

  • I was able to do the exact same without modifying MCUboot.  I put MCUboot hooks in board.c as that file is compiled by both the APP and the child image (mcuboot).  Best practice would put it elsewhere, but it's the least intrusive way.

    In child_image/mcuboot.conf, I set:

    CONFIG_BOOT_IMAGE_ACCESS_HOOKS=y
    CONFIG_BOOT_IMAGE_ACCESS_HOOK_NRF5340=n

    In my board's associated CMakeLists.txt file, I set:

    zephyr_library_include_directories(${ZEPHYR_MCUBOOT_MODULE_DIR}/boot/bootutil/include)
    zephyr_library_include_directories(${ZEPHYR_MCUBOOT_MODULE_DIR}/boot/zephyr/include)

    Then defined the following functions in board.c. You'll need to write your own system_led_blink() function.

    #include <bootutil/image.h>
    #include <bootutil/bootutil.h>
    
    //-----------------------------------------------------------------------------
    int boot_perform_update_hook(int img_index, struct image_header *img_head, const struct flash_area *area)
    {
        system_led_blink(LED_COLOR_OFF, LED_COLOR_PURPLE, 250);
        return BOOT_HOOK_REGULAR;
    }
    
    //-----------------------------------------------------------------------------
    int boot_read_swap_state_primary_slot_hook(int image_index, struct boot_swap_state *state)
    {
        return BOOT_HOOK_REGULAR;
    }
    
    //-----------------------------------------------------------------------------
    fih_int boot_image_check_hook(int img_index, int slot)
    {
        FIH_RET(fih_int_encode(BOOT_HOOK_REGULAR));
    }
    
    //-----------------------------------------------------------------------------
    int boot_copy_region_post_hook(int img_index, const struct flash_area *area, size_t size)
    {
        system_led_set_color(LED_COLOR_WHITE);
        return 0;
    }
    
    //-----------------------------------------------------------------------------
    int boot_read_image_header_hook(int img_index, int slot, struct image_header *img_head)
    {
        return BOOT_HOOK_REGULAR;
    }
  • Thanks for the detailed instructions! I will try this approach and let you know if it works. I'll implement the changes in board.c and make the necessary modifications to the configuration and CMakeLists.txt files. I'll also write the system_led_blink() function. I'll update you on the results soon.

  • Hello,

    Sorry for the late response, but I was busy with some other work. I have tried almost all these solutions, but even the MCUBOOT_INDICATION_LED is not doing anything when my device is downloading the DFU packets from Bluetooth. Can you help me identify which file exactly handles the firmware packets being downloaded from Bluetooth?

    Additionally, I have experience working with the nRF5 SDK, where we used the nrf_dfu_req_handler.c file to handle packet downloads and made changes there. Is there a similar file or handler in the nRF Connect SDK?

    Thank you for your assistance.

    Kind regards,
    Priyesh Shahi

  • Hello Priyesh,

    I apologize, but I won't be able to compare the nRF5 SDK and the nRF Connect SDK because I don't have any experience working with the older nRF5 SDK. I really don't know how it works.

    Regarding the configuration of MCUBOOT_INDICATION_LED, you can check this sample. In the sample, this configuration is used for serial recovery and also shows how to configure the LED.

    Priyesh Shahi said:
    Can you help me identify which file exactly handles the firmware packets being downloaded from Bluetooth?

    I couldn't understand this last point very well. Could you please clarify what you mean by "file" here? In nRF connect SDK OTA DFU is based on BLE service.

    Kind Regards,

    Abhijith

Related