Configure Bluetooth: Peripheral UART application, bootloader and etc.

[Hiihtaja]

Hi !

I have selected sample https://developer.nordicsemi.com/nRF_Connect_SDK/doc/2.2.0/nrf/samples/bluetooth/peripheral_uart/README.html#peripheral-uart

as basis for evaluate USB_CDC_ACM connectivity to app core and USB_CDC_ACM Recovery mode ( app and network core) via MCUBoot bootloader.

I assume SMP server need to be allocated in MCUBoot and App core and Network core can be updated  ( without using any copies in flash memory ) by using mcumgr utility.

1.

I hide some definition in environmental variables for operate with simple command line :

west build --build-dir ./build  . --pristine --board nrf5340dk_nrf5340_cpuapp -- -DBOARD_ROOT=. -DDTC_OVERLAY_FILE="app.overlay" -DCONF_FILE="prj.conf"

this configuration can be compiled and flashed without any problems. I can see some debug traces from DK board via ACM0 and 1 USB serial ports.

I assume VS and command line build environment is configured properly.

2. Change App core connectivity from serial to USB_CDC_ACM according recommendation

west build --build-dir ./build  . --pristine --board nrf5340dk_nrf5340_cpuapp -- -DBOARD_ROOT=. -DDTC_OVERLAY_FILE="usb.overlay" -DCONF_FILE="prj_cdc.conf"

Errors

"

Loaded configuration '/home/yevgen/ncs/v2.2.0/zephyr/boards/arm/nrf5340dk_nrf5340/nrf5340dk_nrf5340_cpuapp_defconfig'
Merged configuration '/home/yevgen/nsctest/cpuapp/prj_cdc.conf'

warning: BT_SMP (defined at subsys/bluetooth/host/Kconfig:317, subsys/bluetooth/host/Kconfig:317) has direct dependencies (BT_CONN && BT_HCI_HOST && BT_RPC_STACK) || (BT_CONN && BT_HCI_HOST && BT_HCI && BT) with value n, but is currently being y-selected by the following symbols:
- BT_NUS_SECURITY_ENABLED (defined at /home/yevgen/nsctest/cpuapp/Kconfig:23), with value y, direct dependencies y (value: y)

error: Aborting due to Kconfig warnings

CMake Error at /home/yevgen/ncs/v2.2.0/zephyr/cmake/modules/kconfig.cmake:328 (message):
command failed with return code: 1

"

if I disable BT security, other errors popups

"

42 | #define DEVICE_NAME CONFIG_BT_DEVICE_NAME
| ^~~~~~~~~~~~~~~~~~~~~
/home/yevgen/ncs/v2.2.0/zephyr/include/zephyr/bluetooth/bluetooth.h:375:30: note: in definition of macro 'BT_DATA'
375 | .data_len = (_data_len), \
| ^~~~~~~~~
../src/main.c:43:33: note: in expansion of macro 'DEVICE_NAME'
43 | #define DEVICE_NAME_LEN (sizeof(DEVICE_NAME) - 1)
| ^~~~~~~~~~~
../src/main.c:76:53: note: in expansion of macro 'DEVICE_NAME_LEN'
76 | BT_DATA(BT_DATA_NAME_COMPLETE, DEVICE_NAME, DEVICE_NAME_LEN),

"

So it is exists some errors in application ?

3. I have returned to original configuration DCONF_FILE="prj.conf" and try to add MCUBoot configuration to application and configure MCUBoot itself.

e.g add extra lines to prj.conf

# MCUBoot serial
CONFIG_MCUBOOT_SERIAL=y
CONFIG_MCUBOOT_SERIAL_DIRECT_IMAGE_UPLOAD=y

# The following configurations are required to support serial recovery of the
# network image
CONFIG_PCD_APP=y

CONFIG_FLASH_SIMULATOR=y
CONFIG_FLASH_SIMULATOR_DOUBLE_WRITES=y
CONFIG_FLASH_SIMULATOR_STATS=n

CONFIG_BOOT_IMAGE_ACCESS_HOOKS=y
CONFIG_NRF53_RECOVERY_NETWORK_CORE=y

CONFIG_MCUBOOT_INDICATION_LED=y

OR

west build --build-dir ./build . --pristine --board nrf5340dk_nrf5340_cpuapp -- -DBOARD_ROOT=. -DDTC_OVERLAY_FILE="app.overlay" -DCONF_FILE="prj.conf" -DOVERLAY_CONFIG="nrf5340dk_mcuboot_sr_net.conf"

and

Merged configuration '/home/yevgen/nsctest/cpuapp/prj.conf'

warning: BOOT_IMAGE_ACCESS_HOOKS (defined at modules/Kconfig.mcuboot_bootutil:24) was assigned the
value 'y' but got the value 'n'. Check these unsatisfied dependencies: MCUBOOT_BOOTUTIL_LIB (=n).
See docs.zephyrproject.org/.../kconfig.html and/or look up
BOOT_IMAGE_ACCESS_HOOKS in the menuconfig/guiconfig interface. The Application Development Primer,
Setting Configuration Values, and Kconfig - Tips and Best Practices sections of the manual might be
helpful too.

warning: FLASH_SIMULATOR (defined at drivers/flash/Kconfig.simulator:6) was assigned the value 'y'
but got the value 'n'. Check these unsatisfied dependencies: DT_HAS_ZEPHYR_SIM_FLASH_ENABLED (=n).
See docs.zephyrproject.org/.../kconfig.html and/or look up
FLASH_SIMULATOR in the menuconfig/guiconfig interface. The Application Development Primer, Setting
Configuration Values, and Kconfig - Tips and Best Practices sections of the manual might be helpful
too.

warning: FLASH_SIMULATOR_DOUBLE_WRITES (defined at drivers/flash/Kconfig.simulator:25) was assigned
the value 'y' but got the value 'n'. Check these unsatisfied dependencies: FLASH_SIMULATOR (=n). See
docs.zephyrproject.org/.../kconfig.html and/or look
up FLASH_SIMULATOR_DOUBLE_WRITES in the menuconfig/guiconfig interface. The Application Development
Primer, Setting Configuration Values, and Kconfig - Tips and Best Practices sections of the manual
might be helpful too.

/home/yevgen/nsctest/cpuapp/prj.conf:53: warning: attempt to assign the value 'y' to the undefined symbol MCUBOOT_SERIAL

/home/yevgen/nsctest/cpuapp/prj.conf:54: warning: attempt to assign the value 'y' to the undefined symbol MCUBOOT_SERIAL_DIRECT_IMAGE_UPLOAD

/home/yevgen/nsctest/cpuapp/prj.conf:65: warning: attempt to assign the value 'y' to the undefined symbol NRF53_RECOVERY_NETWORK_CORE

/home/yevgen/nsctest/cpuapp/prj.conf:67: warning: attempt to assign the value 'y' to the undefined symbol MCUBOOT_INDICATION_LED

error: Aborting due to Kconfig warnings

4. Could it be possible to guide me with MCUBoot configuration for this project ?

The next features are expected:

- SMP server located in MCUBoot only

- Serial recovery method is used for update App and Network cores ( no extra copies of firmware in mcu's flash memory or external serial memory )

- USB_CDC_ACM connectivity to MCUBoot

- Enable multiimage build e.g *zip what contains updates for both cores.

5. Also not so clear how to change child network core project for current image. Looks like it is hardcoded somewhere.

Regards,

Eugene

 

[Sigurd Hellesvik]

Hi,

Instead of answering your questions one by one, I created an example to do the following:

• Serial Recovery over CDC_ACM
• For both cores of the nRF5340
• nRF Connect SDK v2.2.0

mcuboot_serial_recovery_cdc_acm_nrf5340_external_flash_both_cores.zip

The configurations for this sample is based on nRF Machine Learning sample.
The base is from my unofficial Serial Recovery sample.

You upload an update to the network core using:

mcumgr  -c acm0 image upload build/zephyr/net_core_app_update.bin -n 3

PS: You might have to shorten the projects name before building if you use windows.

I hope this can help you.

Let me know which of your questions are still relevant after looking at this sample.

Regards,
Sigurd Hellesvik

[Hiihtaja]

Hi Sigurd Hellesvik !

Thank you !

I'm using Ubuntu 20.04 and latest v2.2.0 SDK for my questions and examples.

Few overall questions about example mcuboot_serial_recovery_cdc_acm_nrf5340_external_flash_both_cores.zip 

I have build iit from command line

west build --pristine --board nrf5340dk_nrf5340_cpuapp -- -DDTC_OVERLAY_FILE="app.overlay"

 1. It looks as most advanced configuration when App and network core is huge and updated via proxy storage ( external memory only or some partitions in app memory ?)

2. I have tried to enable any debug uart traces from both bootloaders but no any luck. Even all flags like UART log are set.

3. What mean -n flag for mcumgr ? It is not visible in help of utility ?

4. How networkapplication hci_rpmg defined as child project ? Definition is not visible in project files. Looks as some trick.

 5. MCUBoot is visible as child image but n0b bootloader not. Does it appears somehow automatically ?

6. Network core image is updated without problem:

mcumgr -c acm2 image upload build/zephyr/net_core_app_update.bin -n 3
181.71 KiB / 181.71 KiB [=========================================================================================================================] 100.00% 1.33 KiB/s 2m16s
Done

But app and composite always freeze at the end.

mcumgr -c acm2 image upload build/zephyr/app_update.bin -n 3
46.77 KiB / 46.91 KiB [====================================================================================================================================] 99.71% 477 B/s

mcumgr -c acm2 image upload build/zephyr/dfu_application.zip -n 3
230.07 KiB / 230.18 KiB [===================================================================================================================================] 99.95% 22 B/s

Should they be updated directly or via hiddent reboot ?

Or how whole flow works in your sample ?

7. I have study sample in more details and by using your example , have changed MCUboot partition  size and move it to USB serial port.

https://developer.nordicsemi.com/nRF_Connect_SDK/doc/2.2.0/nrf/samples/bluetooth/peripheral_uart/README.html#peripheral-uart

App and net cores can be updated one by one.

8. It might be so that sample is close to your picture

https://github.com/hellesvik-nordic/samples_for_nrf_connect_sdk/tree/main/bootloader_samples/nrf5340#non-simultaneous-update

But this moment is not so clear : "When updating the network core, the new image will be saved to the secondary slot. On a reboot, the image will be swapped with the network core over the shared SRAM:"

I look for MCUBoot configuration what updating of both cores are not required usage any spare memory on internal flash memory and external one. 

peripheral uart bootloader configuration ( important parts) looks like this

CONFIG_FLASH=y

# MCUBoot serial
CONFIG_MCUBOOT_SERIAL=y
CONFIG_MCUBOOT_SERIAL_DIRECT_IMAGE_UPLOAD=y

# The following configurations are required to support serial recovery of the
# network image
CONFIG_PCD_APP=y

CONFIG_FLASH_SIMULATOR=y
CONFIG_FLASH_SIMULATOR_DOUBLE_WRITES=y
CONFIG_FLASH_SIMULATOR_STATS=n

CONFIG_BOOT_IMAGE_ACCESS_HOOKS=y
CONFIG_NRF53_RECOVERY_NETWORK_CORE=y

CONFIG_MCUBOOT_INDICATION_LED=y

# Extra
CONFIG_BOOT_SERIAL_CDC_ACM=y
CONFIG_SIZE_OPTIMIZATIONS=y
CONFIG_UART_CONSOLE=y
CONFIG_LOG=y

CONFIG_UPDATEABLE_IMAGE_NUMBER=1

External memory is not defined anywhere, extra partitions as well.

Does this configuration is close to your picture https://github.com/hellesvik-nordic/samples_for_nrf_connect_sdk/tree/main/bootloader_samples/nrf5340#non-simultaneous-update

Or this is something else ?

How can looks configuration when :

- Serial recovery method is required for both cores. e.g. direct update without usage of extra flash slots and external serial memory.

- To avoid external memory usage, the case when application and network core images can be updated separately is also accepted ( but no idea if external memory is really needed in case of serial recovery and multiimage.zip).

- SMP server is located in MCUBoot only ( no need in application ) e.g update is triggered by GPIO line.

  Triggering works as expected and any GPIO line can be configured and I hope SMP server is not included by default in APP.

?

Regards,

Eugene

[Hiihtaja]

Hi Sigurd Hellesvik !

Can we look more close this picture: 

https://github.com/hellesvik-nordic/samples_for_nrf_connect_sdk/tree/main/bootloader_samples/nrf5340#non-simultaneous-update

I'm able to upload network update to second app slot in internal memory by

$ mcumgr -c acm2 image upload -e build/zephyr/net_core_app_update.bin -n 3

when upload complete, MCUboot show traces

..

 Turned on network core

But nothing is not happens after that and after reboot.

Partition info looks correct:

$ west build -t partition_manager_report

-- west build: running target partition_manager_report

[...build/cpunet/partitions_CPUNET.yml

  flash_primary (0x100000 - 1024kB): 

+--------------------------------------------------+

| 0x0: mcuboot (0x18000 - 96kB)                    |

+---0x18000: mcuboot_primary (0x74000 - 464kB)-----+

| 0x18000: mcuboot_pad (0x200 - 512B)              |

+---0x18200: mcuboot_primary_app (0x73e00 - 463kB)-+

| 0x18200: app (0x73e00 - 463kB)                   |

+--------------------------------------------------+

| 0x8c000: mcuboot_secondary (0x74000 - 464kB)     |

+--------------------------------------------------+

 

  otp (0x2fc - 764B): 

+------------------------------+

| 0xff8100: otp (0x2fc - 764B) |

+------------------------------+

 

  ram_flash (0x40000 - 256kB): 

+------------------------------------------+

| 0x0: mcuboot_primary_1 (0x40000 - 256kB) |

| 0x40000: ram_flash (0x0 - 0B)            |

+------------------------------------------+

 

  sram_primary (0x80000 - 512kB): 

+--------------------------------------------+

| 0x20000000: pcd_sram (0x2000 - 8kB)        |

| 0x20002000: sram_primary (0x7e000 - 504kB) |

+--------------------------------------------+

 

 CPUNET flash_primary (0x40000 - 256kB): 

+--------------------------------------------+

+---0x1000000: b0n_container (0x8800 - 34kB)-+

| 0x1000000: b0n (0x8580 - 33kB)             |

| 0x1008580: provision (0x280 - 640B)        |

+---0x1008800: app (0x37800 - 222kB)---------+

| 0x1008800: cpunet (0x37800 - 222kB)        |

+--------------------------------------------+

 

 CPUNET sram_primary (0x10000 - 64kB): 

+-------------------------------------------+

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

+-------------------------------------------+

Looks like I should inform mcuboot or/and b0n that image in that slot and force update somehow.

How I can do it ? Does reboot is mandatory ?

Regards

Eugene

[Sigurd Hellesvik]

Hi,

Hiihtaja said:

Looks like I should inform mcuboot or/and b0n that image in that slot and force update somehow.

How I can do it ? Does reboot is mandatory ?

For SMP Server in the application, you need to tag the new image with either "test" or "confirm".

For Serial Recovery, you upload it directly. Here is a quick sample I made to test this:

mcuboot_netcore_serial_recovery.zip

To upload to the netcore, use

mcumgr  -c acm1 image upload build/zephyr/net_core_app_update.bin  -n 3

Then wait for ca 2 minutes before restarting the device.

Regards,
Sigurd Hellesvik

[Hiihtaja]

Hi !

I should enable in prj.conf few lines in your sample

CONFIG_MCUMGR=y
CONFIG_MCUMGR_SMP_UART=y
CONFIG_MCUMGR_CMD_IMG_MGMT=y

$ mcumgr -c acm1 image upload build/zephyr/net_core_app_update.bin -n 3
181.71 KiB / 181.71 KiB [===============================================================================================================] 100.00% 1.80 KiB/s 1m41s
Done

App image is also uploaded to some space

$ mcumgr -c acm1 image upload build/zephyr/app_update.bin
58.02 KiB / 58.02 KiB [=====================================================================================================================] 100.00% 956 B/s 1m2s
Done

But actual update is not happens.

Partition info

But how images are updated on fly ?

Looks like network and app core is up and running with normal images and need to be 

updated by MCUMGR

Regards,

Eugene

[Sigurd Hellesvik]

Hiihtaja said:

CONFIG_MCUMGR=y
CONFIG_MCUMGR_SMP_UART=y
CONFIG_MCUMGR_CMD_IMG_MGMT=y

The sample is configured for Serial Recovery, so the above configuration is not needed.

To enter Serial Recovery mode, hold Button 1 when resetting.
LED1 should now light up, signaling that the board is in Serial Recovery mode.

Now you can use mcumgr commands.

If you want to use an SMP Server in the Application  instead, try my Non Simultaneous update of nRF5340 sample instead.

Regards,
Sigurd Hellesvik

[Hiihtaja]

Hi !

Yes, I have tried in serial recovery as well. What is partition 3  ? It is SRAM ?

In case of SMP server in application, I think I need flash memory extra space for app and network.

Is this so ?

Regards,

Eugene

[Sigurd Hellesvik]

Hiihtaja said:

Yes, I have tried in serial recovery as well. What is partition 3  ? It is SRAM ?

I think the numbering here is a bit bugged.
So I am not sure which one number 3 is.

My guess is that it is mcuboot_primary_1.

Hiihtaja said:

In case of SMP server in application, I think I need flash memory extra space for app and network.

Is this so ?

I assume you mean external flash?

You do not have to have external flash for this to work.

Since you need a secondary slot, the application only have half flash available, so you may want to have external flash for that reason.

Regards,
Sigurd Hellesvik

[Hiihtaja]

Hi !

Can it be some RAM partition ?

I can see these lines in generated .config

CONFIG_NRF53_RECOVERY_NETWORK_CORE=y
CONFIG_NRF53_MCUBOOT_PRIMARY_1_RAM_FLASH=y
CONFIG_NRF53_RAM_FLASH_SIZE=0x40000

And writing to it translated to network flash ?

Regards,

Eugene

[Sigurd Hellesvik]

From partition_manager_report:

  ram_flash (0x40000 - 256kB): 
+------------------------------------------+
| 0x0: mcuboot_primary_1 (0x40000 - 256kB) |
| 0x40000: ram_flash (0x0 - 0B)            |
+------------------------------------------+
  sram_primary (0x80000 - 512kB): 
+-----------------------------------------------+
| 0x20000000: pcd_sram (0x2000 - 8kB)           |
| 0x20002000: sram_primary (0x6e000 - 440kB)    |
| 0x20070000: rpmsg_nrf53_sram (0x10000 - 64kB) |
+-----------------------------------------------+

As you see, mcuboot_primary_1 is inside ram_flash.

I think that the image is written to mcuboot_primary_1, and then PCD is used to transfer the image to the network core via pcd_sram.

Regards,
Sigurd Hellesvik

[Hiihtaja]

Hi !

But it is not visible any delay like flash whole network image from SRAM to flash,

Can flashing be done block by block ? Or due SHA calculations, it is loaded to SRAM as first step.

Just to understand at what point image verification done in case of app and network images in case of recovery flashing.

Image can be flashed but not boot or if it not pass verification , it is not even flashing.

Regards,

Eugene