LED array indication while dfu process in MCU boot

[Priyesh Shahi]

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.

[Menon]

Hello,

To implement your use case, you need to edit the source code of MCUboot integrated with the SDK. When doing this, you must ensure compatibility with each SDK update. Other than that, I don't foresee any issues.

Kind regards,

Abhijith

[Priyesh Shahi]

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

[Menon]

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

[Priyesh Shahi]

Hi Abhijith,

Thank you for your response.

It's okay if you can't compare the nRF5 SDK and the nRF Connect SDK. thank you for your help with the MCUBOOT_INDICATION_LED configuration.

Regarding the firmware packets, I have managed to implement a solution

Nicolas Goualard said:

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

However, I would still like to know which driver file or BLE service file handles the downloading of packets from BLE. Additionally, it seems the MCUBOOT_INDICATION_LED is only for UART. Even after enabling it, the LED did not blink. I also tried printing logs in the main.c file of zephyr/boot to see where the code sets the LED, but none of those logs printed during a DFU over BLE. The only logs that printed were from the LED initialization function. It appears the indication LED may not be working for DFU over BLE.

[Menon]

hello Priyesh,

Priyesh Shahi said:

However, I would still like to know which driver file or BLE service file handles the downloading of packets from BLE. Additionally, it seems the MCUBOOT_INDICATION_LED is only for UART. Even after enabling it, the LED did not blink. I also tried printing logs in the main.c file of zephyr/boot to see where the code sets the LED, but none of those logs printed during a DFU over BLE. The only logs that printed were from the LED initialization function. It appears the indication LED may not be working for DFU over BLE.

DFU over BLE is primarily managed by the Simple Management Protocol (SMP) service in the nRF Connect SDK. I recommend checking ncs\v2.x.x\zephyr\subsys\mgmt\mcumgr\transport\smp_bt.c, which handles the Bluetooth transport layer specific to SMP, and smp.c, which handles the core SMP.

Yes, you are right that the MCUBOOT_INDICATION_LED feature is typically used for UART-based DFU and might not be directly tied to the BLE DFU process. I think you can achieve this by modifying the SMP callbacks

Kind Regards,

Abhijith

[Priyesh Shahi]

Thank you Abhijith,

I will try with these files also.