Using Serial recovery with the NRF5340

Hello community,

I am using BL5340PA BLE controller board from Liard connectivity which is based on the nRF5340 SoC. The BL5340 module allows all of the base functionality in the nrf5340 module, but also adds an external FEM in increase the TX power. I am using the BL5340 as a bluetooth controller / bluetooth adapter for one of my project and I want to implement DFU for the same.

To implement a firmware update I want to use the serial recovery method. I have gone through the examples mentioned by   in his github repo here: https://github.com/hellesvik-nordic/samples_for_nrf_connect_sdk/tree/main/bootloader_samples/serial_recovery

I am fairly new to this so It is a bit difficult for me to understand how exactly to use this feature.

What my project demands is that the BL5340 board to act as a Bluetooth controller which will run either the Bluetooth HCI_USB or the Bluetooth HCI_UART program to scan advertising BLE devices, pair with them and then get data from them.

The firmware update the the BL5340 board could cocur at runtime, the sequence of operation could be as follows : 

1. The BL5340 run the HCI_UART of the HCI_USB program while in operation

2. A firmware update to the board is triggered

3. Some sort of custom HCI command would be needed that resets the BL5340 board and makes it go into serial recovery mode (A reset of the board to be done using some command because I would not have physical access to any buttons )

4.Once in the serial recovery mode, the firmware update is done using mcumgr command and the new image would be confirmed.

5. Once the new image is confirmed, the board , upon reset will start running the new firmware.

Can any one help me in understanding how to implement serial recovery from scratch? I had gone through the serial recovery examples by Sigurd but was not able to understand them completely. Any help on this would greatly help! Thanks

  • Hi Utsav

    I think my best recommendation would be to go through our lesson on Bootloaders and DFU in the NCS Intermediate course. It gives a very good understand how DFU and how everything fits together. 

    Regards

    Runar

  • Thank you so much   for the suggestion. I will definately go through the course material to know more about DFU.

    I had gone through some applications on serial recovery and was successfully able to do a firmware update on my DK board.

    I wish to ask one thing which is about creating a custom HCI command to reset the board in case a firmware update has to be done in runtime. I would be using the Custom BL5340 board that does not have support for any button reset and it may not be possible for me to restart the entire system to go into recovery mode.

    How can I create a custom HCI command that I can execute at runtime so that the board goes into recovery mode?

  • Hi

    In general I don't think it would lead anywhere to create a custom HCI command since it would only affect the network core and not reset the application core for the 5340. I presume you are using HCI_USB, and there is a PR for adding a warning regarding it. I think the best solution would be to either forward a GPIO to the network core that you connect to the reset pin, so you can trigger a reset for application core and enter bootloader option. 

    Another alternative would be to configure the application so that it enter bootloader mode for a few seconds every time you reboot your device. 

    I would also suggest looking into HCI_UART over usb then using hci_usb. To cite a coworker "I get the impression that hci over usb as a transport layer is slightly unstable by design; for simple use cases where transfer is not stressed then hci_usb is functional, but for stability you should use uart or spi as hci transport. It seems as most vendors use uart hci transport due to this, e.g. in phones, laptops etc. We plan to add a disclaimer to the hci_usb sample. A suggested workaround is to use compile hci_uart with the cdc uart driver instead (if you need to use usb, and cant use uart or spi directly)." 

    Regards

    Runar

Related