nRF5340 ESB OTA

[Domziy]

Hello,

I have tested the smp_svr with hci_rpmsg Bluetooth OTA feature and I have successfully uploaded the firmware which worked with the old device manager Android app. I would like to use 2 nrf5340 with ESB protocol. What would be a good starting point do I use the hci_rpmsg existing code and enable ESB and configure it as such or is it better to use bootloader UART code? I am a bit stuck as the hci_rpmsg sample code is dependent on bluetooth defines and ESB and bluetooth give an error message when both are enabled. So if you could give me some guidance on the right decision and how I should handle the problem. Thank you

I am using:
2x NRF5340 DK 
nRF Connect for desktop v4.1.2
nRF Connect SDK v2.4.0

[Simonr]

Hi again

You're overcomplicating things quite a bit as you won't need to jump into the IPC service and specify what the APP and NET core does. The SMP server sample with a Bluetooth LE overlay would be the recommended way to go forward, documentation available here: https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/zephyr/samples/subsys/mgmt/mcumgr/smp_svr/README.html 

Alternatively, the bootloader samples from my colleague Sigurd here with some additional insight of how it works in NCS is available in his Github repo: https://github.com/hellesvik-nordic/samples_for_nrf_connect_sdk/tree/main/bootloader_samples 

The IPC service and doing it in this much of a low-level will be a lot of unnecessary hard work, sweat and tears I think.

Best regards,

Simon

[Domziy]

Hello,

I don't exactly need to know what the IPC service does and how it connects to the app core but that pipeline is what send the firmware from the netcore to the app core that handles reflashing. I am only interested on how to packet the firmware data and put it into the ipc service. I am using the SMP server sample with bluetooth overlay as guidance but that example is only viable of the client sending over the data has the packets already assembled in a way that the server understands them as "firmware upgrade". Lets say I have one nrf5340 running stock smp server example code with the bluetooth overlay, and for the other nrf5340 I want it to be acting as the client sending over the firmware. Hypothetical if I program the client with simple bluetooth code that is able to connect to the server nrf5340 with the stock sample code. I then on the client side send over VCOM (cpunet) the raw .bin file to the net core and being connected to the smp server via bluetooth I am sending raw binary packets. When the server receives those how will it now that these bluetooth packets are now for updating the firmware for the app core on the server side? This is what I am trying to understand on how to make these packets so the server can understand what I will send from the client nrf5340 to the server nrf5340.

Thank you for the github repo on the bootloader samples in there I found sample of the "client_smp/smp_client_ble" repo showing off exactly what I am after, but it is based on the nrf52840 chipset. In the client codebase when sending the data over the packets are formed using zcbor functions:


Now because the nrf52840 is a single core chip the radio functions are running on the same core as the smp server, my questions here is if there is another step of encoding/packetizing being done on the nrf5340 IPC as the data moves between cores and if the appcore needs to unpack what come from netcore and then sends the packet further along to the smp server, or is this all the magic behind it?

Looking that the question of my initial ticket I have written down my goal quite poorly but what I am trying to achieve is OTA capabilities between two nrf5340 chipsets using ESB. We can stick with bluetooth for now to test the binary movement from one nrf5340 to the other one being actually flashed with the new binary, mcuboot recognizing it and being able to boot into the new firmware.

Best regards,

Domen

[Sigurd Hellesvik]

I will continue helping in this case.

After thinking a bit about this case I realized that what makes this case different from BLE is that ESB runs only on the network core.

So for BLE, DFU works in two steps: First we move the new image to mcuboot_secondary and tag it to swap. Then we reboot and MCUboot will find this and swap it into mcuboot_primary.
For the nRF5340, there is another step: We need to move the network core image into mcuboot_secondary1, then it will be swapped into the network core. The reason for this is that the application core can not write to network core flash.

In other words, as long as the update goes into the correct place in flash, we do not care about where in flash it goes to.
You can send the binary files in any way you want.

We have the mcumgr library to make this easier for us in zephyr. However, this assumes that the images are received in the application core, as is done with BLE.

So as I see it, you have two choices: Either make a ESB variant of the hci_rpmsg used by BLE, and implement some kind of ESB host in the application core. Then you could simply add ESB as a transport for mcumgr.

Alternatively, you can send the data in whatever way you want to the application core, and then write the updates to the correct slots with our DFU target library, which does not care about transport.

Did I understand your issue correctly?

Bonus: A colleague of mine created  this sample a while ago. Maybe it can serve as some inspiration to how you can communicate between cores with ESB?