b0n with minimal-size rises anomaly 160 warning

Hello 

I have a project, where I need to have NUS-BLE with firmware update functionality and openthread.

BLE and NUS config:

#*****************************************************************************/
#*                                Bluetooth & NUS                            */
#*****************************************************************************/
CONFIG_BT=y
CONFIG_BT_PERIPHERAL=y
# Enable Dynamic name modification
CONFIG_BT_DEVICE_NAME_DYNAMIC=y
# Maximum character of the device name 
CONFIG_BT_DEVICE_NAME_MAX=25
# Only allow one device to connect
CONFIG_BT_MAX_CONN=1
CONFIG_BT_MAX_PAIRED=1

# Enable the NUS service
CONFIG_BT_NUS=y

FOTA config is:

CONFIG_BOOTLOADER_MCUBOOT=y
# TODO: Only use needed config inside this one
CONFIG_NCS_SAMPLE_MCUMGR_BT_OTA_DFU=n 

# Configs from CONFIG_NCS_SAMPLE_MCUMGR_BT_OTA_DFU
# Must
CONFIG_MCUMGR=y
CONFIG_NET_BUF=y
CONFIG_ZCBOR=y
CONFIG_CRC=y
CONFIG_MCUMGR_TRANSPORT_BT=y
#Should
CONFIG_MCUMGR_TRANSPORT_BT_CONN_PARAM_CONTROL=y
CONFIG_IMG_MANAGER=y
CONFIG_STREAM_FLASH=y
CONFIG_FLASH_MAP=y
CONFIG_FLASH=y
CONFIG_MCUMGR_GRP_IMG=y
CONFIG_MCUMGR_GRP_OS=y
CONFIG_MCUMGR_GRP_OS_BOOTLOADER_INFO=y
CONFIG_MCUMGR_TRANSPORT_BT_REASSEMBLY=y
# CONFIG_BT_MAX_CONN=1 in \child_image\multiprotocol_rpmsg.conf needed
# Sets MTU-Size to 495bytes, yay!
CONFIG_NCS_SAMPLE_MCUMGR_BT_OTA_DFU_SPEEDUP=n

# Enable updates for the network core
# Revert of application core is not possible anymore, because netcore can't be reverted
CONFIG_NRF53_UPGRADE_NETWORK_CORE=y
CONFIG_UPDATEABLE_IMAGE_NUMBER=2

Thread config is:

#*****************************************************************************/
#*                                 Thread                                    */
#*****************************************************************************/
# Enable CoAP utils and CoAP protocol
CONFIG_COAP=y
CONFIG_COAP_UTILS=y

# Generic networking options
CONFIG_NETWORKING=y

# L2 OpenThread enabling
CONFIG_NET_L2_OPENTHREAD=y

# Network shell
CONFIG_SHELL=y
CONFIG_OPENTHREAD_SHELL=y
CONFIG_SHELL_ARGC_MAX=26
CONFIG_SHELL_CMD_BUFF_SIZE=416

# Network sockets
CONFIG_NET_SOCKETS=y
CONFIG_NET_SOCKETS_POSIX_NAMES=y
CONFIG_NET_SOCKETS_POLL_MAX=4

# Same network Master Key for client and server
CONFIG_OPENTHREAD_NETWORKKEY="00:11:22:33:44:55:66:77:88:99:aa:bb:cc:dd:ee:ff"

CONFIG_MBEDTLS_SHA1_C=n
CONFIG_FPU=y

With this configuration, the rom usage of the net-core overflowes by 4496 bytes.

This is the partition report of the cpunet:

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

I have found the option to set the b0n bootloader to minimal-size with -Dmultiprotocol_rpmsg_b0n_OVERLAY_CONFIG=overlay-minimal-size.conf 

But know I get the warning about the anomaly 160:

Should I take this warning for serious, or can I supress this warning?

Another option would be to set CONFIG_ASSERT=n in child_image\multiprotocol_rpmsg.conf

This reduces the used size of the cpunet app by 19.5kB. 

Is this the better option, than to have the minimal-size b0n?

Or is it not a good idea to CONFIG_ASSERT=n the cpunet application?

 

Thank you for your help

Kind regards, Chris

Parents
  • Hi!

    But know I get the warning about the anomaly 160:

    It seems related to CONFIG_SYS_CLOCK_EXISTS being set to n , so you could remove CONFIG_SYS_CLOCK_EXISTS=n in overlay-minimal-size.conf 

    Alternatively, you could try to e.g. setting CONFIG_ASSERT_VERBOSE=n  , and see if that saves you the 4496 bytes needed
  • Hi!
    Thank you for your prompt response.

    When I remove CONFIG_SYS_CLOCK_EXISTS=n the build failed with messeage that CONFIG_NRF_RTC_TIMER is not set.
    So I also removed CONFIG_NRF_RTC_TIMER=n.

    But now, the error region `FLASH' overflowed by 4156 bytes comes up

    So it seems, I need to chose between anomaly 160 or 34kB b0n parition.

    Too bad, that the "normal" b0n build only uses 70% of the 34kB

    Any recommondations?

    I also tested CONFIG_ASSERT_VERBOSE=n and it saved me around 12kB.

    And I also found CONFIG_ASSERT_NO_FILE_INFO=y to save another 4kB.

    We are starting developing thread in Q3 this year, but need to deliver first working prototypes to our customer, which later can be updated by BLE-FOTA to thread functions.

    Hence, the partitions need to fixed soon. But until release, we want to support the latest nRF Connect SDK releases.

    Do you think, that 11kB enough reserve for future developments?

    Kind regards, Chris

Reply
  • Hi!
    Thank you for your prompt response.

    When I remove CONFIG_SYS_CLOCK_EXISTS=n the build failed with messeage that CONFIG_NRF_RTC_TIMER is not set.
    So I also removed CONFIG_NRF_RTC_TIMER=n.

    But now, the error region `FLASH' overflowed by 4156 bytes comes up

    So it seems, I need to chose between anomaly 160 or 34kB b0n parition.

    Too bad, that the "normal" b0n build only uses 70% of the 34kB

    Any recommondations?

    I also tested CONFIG_ASSERT_VERBOSE=n and it saved me around 12kB.

    And I also found CONFIG_ASSERT_NO_FILE_INFO=y to save another 4kB.

    We are starting developing thread in Q3 this year, but need to deliver first working prototypes to our customer, which later can be updated by BLE-FOTA to thread functions.

    Hence, the partitions need to fixed soon. But until release, we want to support the latest nRF Connect SDK releases.

    Do you think, that 11kB enough reserve for future developments?

    Kind regards, Chris

Children
  • Hi!

    ChriglSEI said:
    Do you think, that 11kB enough reserve for future developments?
    ChriglSEI said:
    34kB b0n parition.

    Well, the B0n is an immutable first-stage bootloader, you can't update it later.

    The SPU on nRF5340 divides the flash memory space into 64 regions of 16 kB, each with configurable permissions settings. 16 kB won't fit, so therefore the next option is 34 kB.

Related