nRF5340 BLE DFU from NET core

[valeriy_simakov]

Hello! 
Introduction. Responsibilities of the cores in my device:
1. app core. 
1.1. data processing from a stereo microphone
1.2. data sending to net core.
2. net core. 
2.1. ble communication, services supporting. 
2.2. data receiving from app core.

Everything works fine :)
But now I want to add BLE DFU )

As I understood from examples, I should use app core for smp server, so I should use ble communication support on app core, which changes my whole architecture.

Could please anyone help me with that situation? :)

[Sigurd Hellesvik]

Hi,

What you want to do is not the standard way to do stuff, so it is not supported or tested.

However, it can be done.

First, tell me: Do you want to update both cores?

How large is your network core application?

Regards,
Sigurd Hellesvik

[valeriy_simakov]

For both cores:

[192/196] Linking CXX executable zephyr\cpuapp.elf
Memory region    Used Size      Region Size   %age Used
FLASH:               85552 B         1 MB              8.16%
RAM:                  399824 B        448 KB          87.15%
IDT_LIST:           0 GB               2 KB              0.00%

[210/210] Linking C executable zephyr\cpunet.elf
Memory region    Used Size       Region Size  %age Used
FLASH:               254588 B        256 KB          97.12%
RAM:                  56096 B           64 KB           85.60%
SRAM1:              0 GB                64 KB           0.00%
IDT_LIST:            0 GB               2 KB              0.00%

[valeriy_simakov]

Maybe you'll ask about sources, net core code:cpu_net.rar

[Sigurd Hellesvik]

Prologue / Disclaimer

Running the BLE Host on the application core and the BLE Controller on the application core is the common way to use the nRF5340, and we do have experimental support for FOTA with this design. It could be less work to use the common way instead of what you do, so consider changing your design.

That said, I will now explain two ways you could implement FOTA with the full BLE stack on the network core, and context needed to understand this.

Background

I recommend reading our DevAcademy course on bootloaders and DFU. While this covers the "common way" of nRF5340 setup, the concepts will be helpful in understanding my explanations here. This method will also be very close to one of my explanations below.

For the nRF5340, the network core can access application core flash.
For the nRF5340, the application core can not access network core flash.
Because of the latter, DFU of the network core from the application core must go via shared RAM. This is one of the main reasons for the complexity we see in nRF5340 DFU.

For FOTA, we want to have a backup partition, so we can revert to the previous application in case the FOTA. This feature requires an extra slot in flash, effectively halving flash size. However, since the netcore flash size is small, we will not be able to fit a secondary slot in the network core flash.
Also, netcore DFU from the application core does not support Revert. Because of this, none of the solutions will support a the "revert to backup" feature.

I see that you run your own method of communication between the cores, right? Just wanted to mention that we do have the RPC protocol to do something similar. Just mentioning the Remote Procedure Call (RPC) in case someone sees this later, as I think FOTA for RPC would look similar to what you try to do.

Lastly, I see that you use 97% of the network core flash. FOTA will require a bootloader on the network core, and some extra features, so you likely will have to do some memory optiomizations for your project to make space for the extra things.

Two ways to do FOTA

There are probably more methods to do this, but here are the two best ones as I see it:

Alternative 1: Pretend Appcore does the FOTA

This method is less elegant, but uses the existing FOTA framework so it will likely be easier to implement.

1. Enable FOTA for the nRF5340 as normal as explained in the DevAcademy course on bootloaders and DFU.

2. Add a FOTA handler to the network core code that receives the image and sends it to the application core as data.

3. On the application core, receive the image using the DFU Target library. DFU Target will write the image to the correct slots in flash.

4. When the FOTA images are in the correct slots in the application core flash, FOTA can be done as normal, where the application core updates both cores.

Alternative 2: Write to application core flash

Since the network core can technically write to application core flash, we can use this method to do DFU more directly.

1. Find out how to grant network core access to application core flash, and try to write directly to the application core flash.

2. For application core DFU, overwrite mcuboot_primary of the application core directly from the network core.

3. For network core DFU, write to mcuboot_secondary_1 directly from network core. Then the application core should be able to do FOTA to the network core. This is done from MCUboot, using our "Netcore DFU feature". Since network core flash is limited, we have to update the network core from the application core I think.

[valeriy_simakov]

Sigurd Hellesvik thank you for your detailed answer! 
 1. Flash usage. 
I checked memory distribution on the net core with sample 'peripheral_lbs' for nrf5340dk borad.

CPUNET flash_primary (0x40000 - 256kB):
+--------------------------------------------+
+---0x1000000: b0n_container (0x8800 - 34kB)-+
| 0x1000000: b0n (0x8580 - 33kB) |
| 0x1008580: provision (0x280 - 640B) |
+---0x1008800: app (0x37800 - 222kB)---------+
| 0x1008800: hci_rpmsg (0x37800 - 222kB) |
+--------------------------------------------+

CPUNET sram_primary (0x10000 - 64kB):
+-------------------------------------------+
| 0x21000000: sram_primary (0x10000 - 64kB) |
+-------------------------------------------+

  So yes, I should reduce flash usage on the net core to be able to use  b0n bootloader.

 
2. Alternative 1
Could you please explane how to add FOTA handler to the network core or where I can find the example?

[Sigurd Hellesvik]

valeriy_simakov said:

Could you please explane how to add FOTA handler to the network core or where I can find the example?

Well we dont have any example as such. For the application core we use the mcumgr library for this, but this will just write to flash directly. For Alt1, you would want to transfer the DFU image received to the application core. I think this can be done in one of three ways:

A: Trick/patch the mcumgr library to make it send data to the application core instead of writing to flash.

B: Write a BLE service that uses the SMP Protocol to receive the DFU and send it to the application core.

C: Write a custom BLE service that receives a custom binary with your DFU files and send it to the application core

[valeriy_simakov]

Sigurd Hellesvik 
* Thanks, I will investigate all three ways. 

* Net core flash usage is so big. I reduced it by logging disabling. Could you please tell me how to reduce it more efficiently? I attached the file from 'rom_report'. The section 'no paths' takes 50% :(
net_core_flash_usage.txt

* To be honest, I had doubts about my architecture. The app core continuously accumulates data from the microphone for a certain time and transmits it in chunks to the network core, which then sends the data via BLE. I did this to unload the app core so that it would not send data over BLE. Maybe I use the wrong way and there would be no problems with continuously receiving and sending data. I need your opinion.

[valeriy_simakov]

static struct bt_gatt_attr smp_bt_attrs[] = {

    /* SMP Primary Service Declaration */

    BT_GATT_PRIMARY_SERVICE(&smp_bt_svc_uuid),

    BT_GATT_CHARACTERISTIC(&smp_bt_chr_uuid.uuid,

                   BT_GATT_CHRC_WRITE_WITHOUT_RESP |

                   BT_GATT_CHRC_NOTIFY,

#ifdef CONFIG_MCUMGR_TRANSPORT_BT_AUTHEN

                   BT_GATT_PERM_WRITE_AUTHEN,

#else

                   BT_GATT_PERM_WRITE,

#endif

                   NULL, smp_bt_chr_write, NULL),

    BT_GATT_CCC(smp_bt_ccc_changed,

#ifdef CONFIG_MCUMGR_TRANSPORT_BT_AUTHEN

                   BT_GATT_PERM_READ_AUTHEN |

                   BT_GATT_PERM_WRITE_AUTHEN),

#else

                   BT_GATT_PERM_READ | BT_GATT_PERM_WRITE),

#endif

};

With corresponding CONFIG_x values in 'peripheral_lbs' example we have attributes without response where mcumgr writes the data. 
I think I can write BLE service wrapper of smp service to get data and send it to app core (data, len). On app core I can write smp_uart wrapper to receive data. What do you think about it?