nRF5340 ESB OTA

RE: nRF5340 ESB OTA

Sigurd Hellesvik — Wed, 22 Nov 2023 14:23:51 GMT

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?

RE: nRF5340 ESB OTA

Domziy — Sun, 19 Nov 2023 17:46:46 GMT

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

RE: nRF5340 ESB OTA

Simonr — Tue, 14 Nov 2023 13:25:50 GMT

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

RE: nRF5340 ESB OTA

Domziy — Mon, 13 Nov 2023 14:57:47 GMT

Hey Simon,

thank you for your information. What I am after here is the understanding of the application core writing to flash or rather how to packetize the binary app_update.bin when received by the network core into a structure which is then sent over IPC to the app core, where the app core then writes onto flash. From the documentation you have sent it says that the application core cannot access the flash of the network core, I assume that the network core cannot access the applications core's flash either. So my question is when I received the binary data in the network core I want to sent this now to the app core, assuming this transfer is being done in the IPC_service, how do I need to structure the binary data and packetize it so when I send it over to the app core that it flashes the new binary?

In my previous post the second image is a printout of what is being sent through the IPC service. Infont of the packets sent is I assume a command and padding of sorts following the data. When I initiate the firmware update through bluetooth with the device manager android app, you can distinguish that the data sent is the binary file. What I would like to do is use the ESB example for the network core, open the same IPC service, packetize the gotten binary as it needs to be and send it to the app core. I am just stuck at the stage understanding on how to make this packets for the app core to decipher that the sent data is the binary update.

I am assuming this is the procedure of writing the binary data gotten from the network core that updates the app core. If it is different in fact, please let me know how it is done.

Best regards,

Domen

RE: nRF5340 ESB OTA

Simonr — Mon, 13 Nov 2023 14:18:58 GMT

Hi Domen

I think you're on a bit lower level here than what you need to be in NCS. We have a library for specifically sending DFU images to the NET core on the nRF5340 here.

I'm not very familiar with the IPC service I'm afraid, but I think that the secondary partition for the NET core image is configured in the shared RAM between the NET and APP cores. So the NET core will take care of swapping the NET core's image in this case, and that would be why you don't see mentions of the IPC in the mgmt.c.

Best regards,

Simon

RE: nRF5340 ESB OTA

Domziy — Fri, 10 Nov 2023 14:41:47 GMT

Hello Simon,

I see, thank you for the references. With the smp_svr sample and included hci_rpmsg the hci_rpmsg opens up the IPC service like how it is described in the .dts file on the shared memory. From what I understand some task in the application core opens the same instance and they start communicating through that medium. The application task that communicates through IPC I assume is writing to flash. But the packets are formed in a certain way so that the task knows if that is for being written to flash or any other commands based on the packet. In the smp_svr main.c there isn't anything that shows opening any IPC service so I assume the task is initialized prior with the configs and runs in the back. When I list the tasks the kernel can show it looks like this:

Looking into mcumgr smp in your github under nrfconnect/sdk-zephyr/subsys/mgmt/mcumgr/mgmt/src/mgmt.c I thought that is the task that communicates with the network core and flashes things but looks like some other task is responsible for that. Now my question is which task/thread/project in this sample project is writing to the flash with the information from the network core? And if you maybe have documentation or API on how this packets are structured for the app IPC task to write to flash. From the log of what is send to the ipc_service_send function in the hci_rpmsg you get information like this:

And it looks like there is a structure behind the data packets with commands infront with the following data. I would then structure the same packets from the information that I get from ESB and send it through the same IPC process.

Best regards,

Domen

RE: nRF5340 ESB OTA

Simonr — Fri, 10 Nov 2023 11:41:25 GMT

Hi Domen

The IPC service and its API is well described in the Zephyr project documentation here, and you can either use the IPC service shell transport or IPC UART driver to send data over UART to another processor. Let me know if you run into any problems.

Best regards,

Simon

RE: nRF5340 ESB OTA

Domziy — Thu, 09 Nov 2023 11:41:45 GMT

Hello,

Alright if I use ESB+BLE sample as is for the CPUNET core of the NRF5340 I still need to convey the ESB data to the secondary image slot via the ipc_service. Can you guide me on any documentation on how to interface via the "ipc_service_send" function that the hci_rpmsg is using? I would need information now on how the ipc_service works and how I need to packetize the data for the new binary to be stored in the flash and that the bootloader "sees" a new secondary image.

Best regards,

Domen

RE: nRF5340 ESB OTA

Simonr — Fri, 27 Oct 2023 13:19:41 GMT

Hi again

After a bit of digging around researching your issue I found/was made aware of this GitHub sample by one of our devs that have passed by me. It is an ESB + BLE sample for the nRF5340 that should build/run as is. Can you take a look at that, as these prj.conf snippets don't tell me much, and the ESB expert here on tech support is currently busy, so what specifics we can help with are a bit limited at the time being unfortunately.

Best regards,

Simon

RE: nRF5340 ESB OTA

Domziy — Thu, 26 Oct 2023 12:37:20 GMT

Hello,

I am modifying the hci_rpmsg project that gets called from smp_svr as child image. I am trying to build only the hci_rpmsg project now for the nrf5340_cpunet core but with the included files from the github the build always fails based on missing configs. I modified the prj.conf of the hci_rpmsg project like this:

CONFIG_IPC_SERVICE=y
CONFIG_MBOX=y

CONFIG_HEAP_MEM_POOL_SIZE=8192

CONFIG_MAIN_STACK_SIZE=512
CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=512

CONFIG_BT=y
CONFIG_BT_HCI=y
CONFIG_BT_HCI_RAW=n
#CONFIG_BT_HCI_RAW_RESERVE=1
#CONFIG_BT_MAX_CONN=16

CONFIG_BT_RPC_STACK=y
#CONFIG_BT_HCI_HOST=y


CONFIG_BT_MAX_PAIRED=2
# Workaround: Unable to allocate command buffer when using K_NO_WAIT since
# Host number of completed commands does not follow normal flow control.
CONFIG_BT_BUF_CMD_TX_COUNT=10

# Enable and adjust the below value as necessary
# CONFIG_BT_BUF_EVT_RX_COUNT=16
# CONFIG_BT_BUF_EVT_RX_SIZE=255
# CONFIG_BT_BUF_ACL_RX_SIZE=255
# CONFIG_BT_BUF_ACL_TX_SIZE=251
# CONFIG_BT_BUF_CMD_TX_SIZE=255

Some of the old things like CONFIG_BT_HCI_RAW I had to disable as CONFIG_BT_MAX_PAIRED has dependencies on CONFIG_BT_HCI_HOST that has dependencies on !CONFIG_BT_HCI_RAW. I have added the ones that had dependencies form others. But the problem now is BT_MAX_PAIRED still isn't assignable because BT_CONN isn't set. BT_CONN cannot be user set and is dependent on CONFIG_BT and CONFIG_BT_HCI which are both set and yet the system gives me back that CONFIG_BT_CONN=n. Picture from nRF Kconfig GUI:

I would like to use the smp_svr + hci_rpmsg as it is a good starting point on porting the transmission protocol from bluetooth to ESB and just reverse engineer the packets and how to send the binary over ESB and keep the stack that writes the packets into the bootloader. If you have any other better suggestion on how to solve this or another angle please let me know.

Best regards,

Domen

RE: nRF5340 ESB OTA

Simonr — Tue, 24 Oct 2023 10:42:00 GMT

How does your config file look here? The error messages seem to be struggling to find CONFIG_BT_MAX_PAIRED which should be enabled in the configs of the Bluetooth Host controller. I think starting out with a Bluetooth sample and adding ESB features will be easier than adding the overlay-bt.conf altogether on your end. Have you made sure that the NET core has the Bluetooth controller enabled in its configs as well (should be done in the child image).

Best regards,

Simon

RE: nRF5340 ESB OTA

Domziy — Sun, 22 Oct 2023 19:08:13 GMT

Hello, I am trying to implement your colleagues ESB+BT example on the nrf5340 but I get undeclared config errors even though it is configured in the project. I am using the same sample code smp_svr with the overlay-bt.conf in the build configuration. I have modified the hci_rpmsg CMakeLists.txt in the SDK with the one used in the ESB+BT example of including the c file sources and library directories. When the source files and directory is included I get the error of:
=== child image b0n - CPUNET (inherited) end ===

CMake Warning at C:/ncs/v2.4.2/nrf/subsys/bootloader/cmake/debug_keys.cmake:36 (message):

      --------------------------------------------------------------
      --- WARNING: Using generated NSIB public/private key-pair. ---
      --- It should not be used for production.                  ---
      --- See CONFIG_SB_SIGNING_KEY_FILE                         ---
      --------------------------------------------------------------


Call Stack (most recent call first):
C:/ncs/v2.4.2/nrf/subsys/bootloader/cmake/provision_hex.cmake:37 (include)
C:/ncs/v2.4.2/nrf/subsys/CMakeLists.txt:17 (include)

-- libmetal version: 1.3.0 (C:/ncs/v2.4.2/zephyr/samples/bluetooth/hci_rpmsg)
-- Build type:
-- Host:    Windows/AMD64
-- Target: Generic/arm
-- Machine: arm
-- open-amp version: 1.3.0 (C:/ncs/v2.4.2/modules/lib/open-amp/open-amp)
-- Host:    Windows/AMD64
-- Target: Generic/arm
-- Machine: arm
-- C_FLAGS : -Wall -Wextra
CMake Warning at ../../../CMakeLists.txt:839 (message):
No SOURCES given to Zephyr library: lib__libc__common

Excluding target from build.

-- Configuring done
-- Generating done
-- Build files have been written to: C:/Ntest/smp_svr/build/hci_rpmsg
[0/244] Performing build step for 'b0n_subimage'
[1/29] Generating misc/generated/syscalls.json, misc/generated/struct_tags.json
[2/29] Building C object zephyr/CMakeFiles/zephyr.dir/C_/ncs/v2.4.2/nrf/subsys/partition_manager/flash_map_partition_manager.c.obj
[3/29] Building C object modules/nrf/subsys/bootloader/bl_crypto/CMakeFiles/..__nrf__subsys__bootloader__bl_crypto.dir/bl_crypto_oberon_hash.c.obj
[4/29] Building C object CMakeFiles/app.dir/src/main.c.obj
[5/29] Building C object modules/nrf/subsys/bootloader/bl_boot/CMakeFiles/..__nrf__subsys__bootloader__bl_boot.dir/bl_boot.c.obj
[6/29] Generating linker_zephyr_pre0.cmd
[7/29] Generating linker_zephyr_pre1.cmd
[8/29] Building C object modules/nrf/subsys/bootloader/bl_crypto/CMakeFiles/..__nrf__subsys__bootloader__bl_crypto.dir/bl_crypto.c.obj
[9/29] Building C object modules/nrf/subsys/bootloader/bl_storage/CMakeFiles/..__nrf__subsys__bootloader__bl_storage.dir/bl_storage.c.obj
[10/29] Building C object modules/nrf/subsys/pcd/CMakeFiles/..__nrf__subsys__pcd.dir/src/pcd.c.obj
[11/29] Building C object modules/nrf/subsys/bootloader/bl_validation/CMakeFiles/..__nrf__subsys__bootloader__bl_validation.dir/bl_validation.c.obj
[12/29] Building C object modules/nrf/subsys/fw_info/CMakeFiles/..__nrf__subsys__fw_info.dir/fw_info.c.obj
[13/29] Linking C static library app\libapp.a
[14/29] Linking C static library modules\nrf\subsys\bootloader\bl_boot\lib..__nrf__subsys__bootloader__bl_boot.a
[15/29] Linking C static library modules\nrf\subsys\bootloader\bl_crypto\lib..__nrf__subsys__bootloader__bl_crypto.a
[16/29] Linking C static library modules\nrf\subsys\bootloader\bl_storage\lib..__nrf__subsys__bootloader__bl_storage.a
[17/29] Linking C static library modules\nrf\subsys\pcd\lib..__nrf__subsys__pcd.a
[18/29] Linking C static library modules\nrf\subsys\fw_info\lib..__nrf__subsys__fw_info.a
[19/29] Linking C static library modules\nrf\subsys\bootloader\bl_validation\lib..__nrf__subsys__bootloader__bl_validation.a
[20/29] Linking C static library zephyr\libzephyr.a
[21/29] Linking C executable zephyr\zephyr_pre0.elf

[22/29] Generating dev_handles.c
[23/29] Building C object zephyr/CMakeFiles/zephyr_pre1.dir/dev_handles.c.obj
[24/29] Linking C executable zephyr\zephyr_pre1.elf

[25/29] Generating linker.cmd
[26/29] Generating isr_tables.c, isrList.bin
[27/29] Building C object zephyr/CMakeFiles/zephyr_final.dir/dev_handles.c.obj
[28/29] Building C object zephyr/CMakeFiles/zephyr_final.dir/isr_tables.c.obj
[29/29] Linking C executable zephyr\zephyr.elf
Memory region         Used Size Region Size %age Used
           FLASH:       23530 B      34176 B     68.85%
             RAM:        3456 B        64 KB      5.27%
           SRAM1:          0 GB        64 KB      0.00%
        IDT_LIST:          0 GB         2 KB      0.00%
[18/244] Building C object zephyr/CMakeFiles/zephyr.dir/C_/ncs/v2.4.2/nrf/subsys/bluetooth/services/lbs.c.obj
FAILED: zephyr/CMakeFiles/zephyr.dir/C_/ncs/v2.4.2/nrf/subsys/bluetooth/services/lbs.c.obj
C:\ncs\toolchains\31f4403e35\opt\zephyr-sdk\arm-zephyr-eabi\bin\arm-zephyr-eabi-gcc.exe -DEXT_API_MAGIC=0x281ee6de,0xb845acea,13570 -DFIRMWARE_INFO_MAGIC=0x281ee6de,0x8fcebb4c,13570 -DKERNEL -DNRF5340_XXAA_NETWORK -DUSE_PARTITION_MANAGER=1 -DVALIDATION_INFO_MAGIC=0x281ee6de,0x86518483,79106 -DVALIDATION_POINTER_MAGIC=0x281ee6de,0x6919b47e,79106 -D__PROGRAM_START -D__ZEPHYR__=1 -IC:/ncs/v2.4.2/zephyr/kernel/include -IC:/ncs/v2.4.2/zephyr/arch/arm/include -IC:/ncs/v2.4.2/nrf/drivers/mpsl/clock_control -IC:/ncs/v2.4.2/zephyr/include -Izephyr/include/generated -IC:/ncs/v2.4.2/zephyr/soc/arm/nordic_nrf/nrf53 -IC:/ncs/v2.4.2/zephyr/soc/arm/nordic_nrf/common/. -IC:/ncs/v2.4.2/zephyr/subsys/bluetooth -IC:/ncs/v2.4.2/nrf/include -IC:/ncs/v2.4.2/nrf/lib/multithreading_lock/. -IC:/ncs/v2.4.2/nrf/subsys/bluetooth/controller/. -IC:/ncs/v2.4.2/nrf/tests/include -IC:/ncs/v2.4.2/modules/hal/cmsis/CMSIS/Core/Include -IC:/ncs/v2.4.2/modules/hal/nordic/nrfx -IC:/ncs/v2.4.2/modules/hal/nordic/nrfx/drivers/include -IC:/ncs/v2.4.2/modules/hal/nordic/nrfx/mdk -IC:/ncs/v2.4.2/zephyr/modules/hal_nordic/nrfx/. -Imodules/libmetal/libmetal/lib/include -IC:/ncs/v2.4.2/modules/lib/open-amp/open-amp/lib/include -IC:/ncs/v2.4.2/modules/crypto/tinycrypt/lib/include -IC:/ncs/v2.4.2/nrfxlib/mpsl/include -IC:/ncs/v2.4.2/nrfxlib/mpsl/include/protocol -IC:/ncs/v2.4.2/nrfxlib/softdevice_controller/include -isystem C:/ncs/v2.4.2/zephyr/lib/libc/minimal/include -isystem c:/ncs/toolchains/31f4403e35/opt/zephyr-sdk/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/include -isystem c:/ncs/toolchains/31f4403e35/opt/zephyr-sdk/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/include-fixed -fno-strict-aliasing -Os -imacros C:/Ntest/smp_svr/build/hci_rpmsg/zephyr/include/generated/autoconf.h -ffreestanding -fno-common -g -gdwarf-4 -fdiagnostics-color=always -mcpu=cortex-m33+nodsp -mthumb -mabi=aapcs --sysroot=C:/ncs/toolchains/31f4403e35/opt/zephyr-sdk/arm-zephyr-eabi/arm-zephyr-eabi -imacros C:/ncs/v2.4.2/zephyr/include/zephyr/toolchain/zephyr_stdint.h -Wall -Wformat -Wformat-security -Wno-format-zero-length -Wno-pointer-sign -Wpointer-arith -Wexpansion-to-defined -Wno-unused-but-set-variable -Werror=implicit-int -fno-pic -fno-pie -fno-asynchronous-unwind-tables -fno-reorder-functions --param=min-pagesize=0 -fno-defer-pop -fmacro-prefix-map=C:/ncs/v2.4.2/zephyr/samples/bluetooth/hci_rpmsg=CMAKE_SOURCE_DIR -fmacro-prefix-map=C:/ncs/v2.4.2/zephyr=ZEPHYR_BASE -fmacro-prefix-map=C:/ncs/v2.4.2=WEST_TOPDIR -ffunction-sections -fdata-sections -std=c99 -nostdinc -MD -MT zephyr/CMakeFiles/zephyr.dir/C_/ncs/v2.4.2/nrf/subsys/bluetooth/services/lbs.c.obj -MF zephyr\CMakeFiles\zephyr.dir\C_\ncs\v2.4.2\nrf\subsys\bluetooth\services\lbs.c.obj.d -o zephyr/CMakeFiles/zephyr.dir/C_/ncs/v2.4.2/nrf/subsys/bluetooth/services/lbs.c.obj -c C:/ncs/v2.4.2/nrf/subsys/bluetooth/services/lbs.c
In file included from C:\ncs\v2.4.2\nrf\subsys\bluetooth\services\lbs.c:23:
C:\ncs\v2.4.2\zephyr\include\zephyr\bluetooth\gatt.h:727:34: error: 'CONFIG_BT_MAX_PAIRED' undeclared here (not in a function); did you mean 'CONFIG_BT_MAX_CONN'?
727 |         #define BT_GATT_CCC_MAX (CONFIG_BT_MAX_PAIRED + CONFIG_BT_MAX_CONN)
      |                                  ^~~~~~~~~~~~~~~~~~~~
C:\ncs\v2.4.2\zephyr\include\zephyr\bluetooth\gatt.h:745:36: note: in expansion of macro 'BT_GATT_CCC_MAX'
745 |         struct bt_gatt_ccc_cfg cfg[BT_GATT_CCC_MAX];
      |                                    ^~~~~~~~~~~~~~~
[19/244] Building C object CMakeFiles/app.dir/C_/Ntest/ncs-esb-ble-mpsl-demo-master/common/app_bt_lbs.c.obj
FAILED: CMakeFiles/app.dir/C_/Ntest/ncs-esb-ble-mpsl-demo-master/common/app_bt_lbs.c.obj
C:\ncs\toolchains\31f4403e35\opt\zephyr-sdk\arm-zephyr-eabi\bin\arm-zephyr-eabi-gcc.exe -DEXT_API_MAGIC=0x281ee6de,0xb845acea,13570 -DFIRMWARE_INFO_MAGIC=0x281ee6de,0x8fcebb4c,13570 -DKERNEL -DNRF5340_XXAA_NETWORK -DUSE_PARTITION_MANAGER=1 -DVALIDATION_INFO_MAGIC=0x281ee6de,0x86518483,79106 -DVALIDATION_POINTER_MAGIC=0x281ee6de,0x6919b47e,79106 -D__PROGRAM_START -D__ZEPHYR__=1 -IC:/Ntest/ncs-esb-ble-mpsl-demo-master/common -IC:/ncs/v2.4.2/nrf/drivers/mpsl/clock_control -IC:/ncs/v2.4.2/zephyr/include -Izephyr/include/generated -IC:/ncs/v2.4.2/zephyr/soc/arm/nordic_nrf/nrf53 -IC:/ncs/v2.4.2/zephyr/soc/arm/nordic_nrf/common/. -IC:/ncs/v2.4.2/zephyr/subsys/bluetooth -IC:/ncs/v2.4.2/nrf/include -IC:/ncs/v2.4.2/nrf/lib/multithreading_lock/. -IC:/ncs/v2.4.2/nrf/subsys/bluetooth/controller/. -IC:/ncs/v2.4.2/nrf/tests/include -IC:/ncs/v2.4.2/modules/hal/cmsis/CMSIS/Core/Include -IC:/ncs/v2.4.2/modules/hal/nordic/nrfx -IC:/ncs/v2.4.2/modules/hal/nordic/nrfx/drivers/include -IC:/ncs/v2.4.2/modules/hal/nordic/nrfx/mdk -IC:/ncs/v2.4.2/zephyr/modules/hal_nordic/nrfx/. -Imodules/libmetal/libmetal/lib/include -IC:/ncs/v2.4.2/modules/lib/open-amp/open-amp/lib/include -IC:/ncs/v2.4.2/modules/crypto/tinycrypt/lib/include -IC:/ncs/v2.4.2/nrfxlib/mpsl/include -IC:/ncs/v2.4.2/nrfxlib/mpsl/include/protocol -IC:/ncs/v2.4.2/nrfxlib/softdevice_controller/include -isystem C:/ncs/v2.4.2/zephyr/lib/libc/minimal/include -isystem c:/ncs/toolchains/31f4403e35/opt/zephyr-sdk/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/include -isystem c:/ncs/toolchains/31f4403e35/opt/zephyr-sdk/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/include-fixed -fno-strict-aliasing -Os -imacros C:/Ntest/smp_svr/build/hci_rpmsg/zephyr/include/generated/autoconf.h -ffreestanding -fno-common -g -gdwarf-4 -fdiagnostics-color=always -mcpu=cortex-m33+nodsp -mthumb -mabi=aapcs --sysroot=C:/ncs/toolchains/31f4403e35/opt/zephyr-sdk/arm-zephyr-eabi/arm-zephyr-eabi -imacros C:/ncs/v2.4.2/zephyr/include/zephyr/toolchain/zephyr_stdint.h -Wall -Wformat -Wformat-security -Wno-format-zero-length -Wno-pointer-sign -Wpointer-arith -Wexpansion-to-defined -Wno-unused-but-set-variable -Werror=implicit-int -fno-pic -fno-pie -fno-asynchronous-unwind-tables -fno-reorder-functions --param=min-pagesize=0 -fno-defer-pop -fmacro-prefix-map=C:/ncs/v2.4.2/zephyr/samples/bluetooth/hci_rpmsg=CMAKE_SOURCE_DIR -fmacro-prefix-map=C:/ncs/v2.4.2/zephyr=ZEPHYR_BASE -fmacro-prefix-map=C:/ncs/v2.4.2=WEST_TOPDIR -ffunction-sections -fdata-sections -std=c99 -nostdinc -MD -MT CMakeFiles/app.dir/C_/Ntest/ncs-esb-ble-mpsl-demo-master/common/app_bt_lbs.c.obj -MF CMakeFiles\app.dir\C_\Ntest\ncs-esb-ble-mpsl-demo-master\common\app_bt_lbs.c.obj.d -o CMakeFiles/app.dir/C_/Ntest/ncs-esb-ble-mpsl-demo-master/common/app_bt_lbs.c.obj -c C:/Ntest/ncs-esb-ble-mpsl-demo-master/common/app_bt_lbs.c
In file included from C:\Ntest\ncs-esb-ble-mpsl-demo-master\common\app_bt_lbs.c:8:
C:\ncs\v2.4.2\zephyr\include\zephyr\bluetooth\gatt.h:727:34: error: 'CONFIG_BT_MAX_PAIRED' undeclared here (not in a function); did you mean 'CONFIG_BT_MAX_CONN'?
727 |         #define BT_GATT_CCC_MAX (CONFIG_BT_MAX_PAIRED + CONFIG_BT_MAX_CONN)
      |                                  ^~~~~~~~~~~~~~~~~~~~
C:\ncs\v2.4.2\zephyr\include\zephyr\bluetooth\gatt.h:745:36: note: in expansion of macro 'BT_GATT_CCC_MAX'
745 |         struct bt_gatt_ccc_cfg cfg[BT_GATT_CCC_MAX];
      |                                    ^~~~~~~~~~~~~~~
[36/244] Building C object CMakeFiles/app.dir/C_/Ntest/ncs-esb-ble-mpsl-demo-master/common/app_timeslot.c.obj
C:/Ntest/ncs-esb-ble-mpsl-demo-master/common/app_timeslot.c: In function 'mpsl_timeslot_callback':
C:\Ntest\ncs-esb-ble-mpsl-demo-master\common\app_timeslot.c:155:43: warning: implicit declaration of function 'RADIO_IRQHandler' [-Wimplicit-function-declaration]
155 |                         if(m_in_timeslot) RADIO_IRQHandler();
      |                                           ^~~~~~~~~~~~~~~~
[42/244] Building C object zephyr/CMakeFiles/zephyr.dir/lib/os/onoff.c.obj
ninja: build stopped: subcommand failed.
[38/54] Linking C executable zephyr\zephyr.elf
Memory region         Used Size Region Size %age Used
           FLASH:      162336 B     474624 B     34.20%
             RAM:       56892 B       440 KB     12.63%
        IDT_LIST:          0 GB         2 KB      0.00%
[40/54] Generating zephyr/mcuboot_primary.hex
FAILED: modules/nrf/samples/hci_rpmsg_subimage-prefix/src/hci_rpmsg_subimage-stamp/hci_rpmsg_subimage-build hci_rpmsg/zephyr/zephyr.hex hci_rpmsg/zephyr/zephyr.elf hci_rpmsg/zephyr/merged_CPUNET.hex
cmd.exe /C "cd /D C:\Ntest\smp_svr\build\hci_rpmsg && C:\ncs\toolchains\31f4403e35\opt\bin\cmake.exe --build . --"
ninja: build stopped: subcommand failed.
FATAL ERROR: command exited with status 1: 'C:\ncs\toolchains\31f4403e35\opt\bin\cmake.EXE' --build 'c:\Ntest\smp_svr\build'

If I go to the line of "#define BT_GATT_CCC_MAX (CONFIG_BT_MAX_PAIRED + CONFIG_BT_MAX_CONN)" for example and check if it is finding it through ctrl+click it can find it at the "C:/ncs/v2.4.2/zephyr/subsys/bluetooth/host/kconfig and hovering over it showing value 0.

Even if I include the "CONFIG_BT_MAX_PAIRED" into the "hci_rpmsg.conf" in the smp_svr child image folder or directly in the hci_rpmsg prj.conf the error still persists and says that it cannot be set anyway as the default prj.conf of hci_rpmsg project has the CONFIG_BT_HCI_RAW=y but for the CONFIG_BT_MAX_PAIRED you need to enable CONFIG_BT_HCI_HOST which has a dependeny on !BT_HCI_RAW so I don't know what to do at this point and where the error comes from.

RE: nRF5340 ESB OTA

Simonr — Thu, 20 Jul 2023 12:38:53 GMT

DFU over ESB is not very straight forward, so I would recommend using ESB + BLE in the same application perhaps to do DFU OTA with BLE, and then have the application run with ESB. My colleague Torbjørn made an example that shows how to run BLE and ESB concurrently using the MPSL interface here. Alternatively the UART bootloader is an option as well if you don't need to do the DFU over the air.

Best regards,

Simon