Configure Bluetooth: Peripheral UART application, bootloader and etc.

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

 

  • Hi Sigurd Hellesvik !

    Looks like a lot of variants of FW updates and what is currently known state ?

    1. App and Netcore flash memory can be split to 2 banks and firmware updates via reboot.

    2. Similar to 1st case but second copy can be stored in external flash memory.

    3. Serial recovery for app core ( direct flashing ) and 2 nd copy of network core image can be located in app flash memory OR external flash memory.

    So this method might work or might not

    4. Serial recovery for network core is not possible, entire network image should e stored somewhere as first step and updated over reboot. 

    It is not possible to flash network core image on fly e.g by some portions via shared memory.

    But it might be implemented by using hook mechanism .

    Is this so ?

    Just to understand what schemes are work for sure, what can exists and can be configured and what can be implemented by hook mechanism.

    Regards,

    Eugene

  • Hiihtaja said:
    1. App and Netcore flash memory can be split to 2 banks and firmware updates via reboot.

    App flash: 1 bank (Primary slot)
    External flash: 1 bank (Secondary slot)
    Net flash: 1 bank  (Netcore flash)

    The App flash is split into 2 banks. (Primary slot and Secondary slot)
    The Netcore flash only has 1 bank. (Netcore flash)

    SMP Server support: Yes
    Serial Recovery support: require a custom hook or fixing of existing hook

    Hiihtaja said:
    2. Similar to 1st case but second copy can be stored in external flash memory.

    SMP Server support: Yes

    App flash: 1 bank (Primary slot)
    External flash: 1 bank (Secondary slot)
    Net flash: 1 bank  (Netcore flash)


    Serial Recovery support: A(No) or B(Yes)

    A: require a custom hook or fixing of existing hook:

    App flash: 1 bank (Primary slot)
    External flash: 1 bank (Secondary slot)
    Net flash: 1 bank  (Netcore flash)

    B: Works as in the Machine Learning sample, but with 1 extra partition

    App flash: 1 bank (Primary slot)
    External flash: 2 banks (Secondary slot and Secondary Slot 1)
    Net flash: 1 bank  (Netcore flash)

    Hiihtaja said:
    3. Serial recovery for app core ( direct flashing ) and 2 nd copy of network core image can be located in app flash memory OR external flash memory.

    I am unsure what you mean here, but is this not covered by either 1 or 2?

    Hiihtaja said:

    4. Serial recovery for network core is not possible, entire network image should e stored somewhere as first step and updated over reboot. 

    It is not possible to flash network core image on fly e.g by some portions via shared memory.

    But it might be implemented by using hook mechanism .

    Is this so ?

    The Appcore can not write to netcore flash.

    But you can try to use the PCD library from the application to update the netcore.
    That would not be a hook.

    The current design is the folliwng:
    Save netcore update to APPCORE flash.
    On MCUboot start, MCUboot will run a hook.
    This hook checks if there is a netcore update in Secondary slot.
    If netcore update found, use PCD to update netcore.

    So if you use serial recovery, I think the easiest fix is to change the hook or add a new custom hook.

    Regards,
    Sigurd Hellesvik

  • Hi Sigurd Hellesvik !

    If I understood mRF Connect SDK v2.1.0 release note, flag 

    CONFIG_NRF53_RECOVERY_NETWORK_CORE specially designed for support direct update of network core. Like MCUBoot should load complete network image to shared SRAM and after that network core will update own flash.  This is simplest scheme of firmware update and may be it is implemented like this. Need to be investigated.

    Or how I should understand "So if you use serial recovery, I think the easiest fix is to change the hook or add a new custom hook." ? It is implemented and need some error fix or it is expected to work in other way ?

    Regards,

    Eugene

  • Hi,

    Hiihtaja said:
    CONFIG_NRF53_RECOVERY_NETWORK_CORE

    I have not seen this one before!

    But it looks like you should be able to use Serial Recovery to update the netcore using this option.
    Then you will not need hooks I think.

    I see that there are overlays in The Bluetooth Peripheral UART sample.

    Try this to see if it works.

    Regards,
    Sigurd Hellesvik

  • 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

Related