Using the nrf52820 as BLE proxy to UART/SPI

[Artnia]

Hi guys,

we are planing to use the nRF52820 as BLE proxy to UART/SPI. It shall receive data from a host controller via UART/SPI and forward it via BLE to a smart phone. Also vice versa it will receive data from a smart phone via BLE and forward it via UART/SPI to the host controller. FOTA shall be also a functionality - also some other functionalities shall be added, but nothing too big.

If i understand correctly the sample "Peripheral UART" is perfect for this use case (https://developer.nordicsemi.com/nRF_Connect_SDK/doc-legacy/latest/nrf/samples/bluetooth/peripheral_uart/README.html#configuration). It is available for the nRF52820 so I tried to build it with the build config "nrf52833dk/nrf52820", with SDK and tool chain v2.7.0 and the config:

#
# Copyright (c) 2018 Nordic Semiconductor
#
# SPDX-License-Identifier: LicenseRef-Nordic-5-Clause
#

# Enable the UART driver
CONFIG_UART_ASYNC_API=y
CONFIG_NRFX_UARTE0=y
CONFIG_SERIAL=y

CONFIG_GPIO=y

# Make sure printk is printing to the UART console
CONFIG_CONSOLE=y
CONFIG_UART_CONSOLE=y

CONFIG_HEAP_MEM_POOL_SIZE=2048

CONFIG_BT=y
CONFIG_BT_PERIPHERAL=y
CONFIG_BT_DEVICE_NAME="Nordic_UART_Service"
CONFIG_BT_MAX_CONN=1
CONFIG_BT_MAX_PAIRED=1

# Enable the NUS service
CONFIG_BT_NUS=y

# Enable bonding
CONFIG_BT_SETTINGS=y
CONFIG_FLASH=y
CONFIG_FLASH_PAGE_LAYOUT=y
CONFIG_FLASH_MAP=y
CONFIG_NVS=y
CONFIG_SETTINGS=y

# Enable DK LED and Buttons library
CONFIG_DK_LIBRARY=y

# This example requires more stack
CONFIG_MAIN_STACK_SIZE=1152
CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=2048

# Config logger
CONFIG_LOG=y
CONFIG_USE_SEGGER_RTT=y
CONFIG_LOG_BACKEND_RTT=y
CONFIG_LOG_BACKEND_UART=n
CONFIG_LOG_PRINTK=n

CONFIG_ASSERT=y

but it fails:

/home/art/ncs/toolchains/e9dba88316/opt/zephyr-sdk/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld.bfd: zephyr/zephyr_pre0.elf section `noinit' will not fit in region `RAM'
/home/art/ncs/toolchains/e9dba88316/opt/zephyr-sdk/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld.bfd: region `RAM' overflowed by 3168 bytes
collect2: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.
FATAL ERROR: command exited with status 1: /home/art/ncs/toolchains/e9dba88316/usr/local/bin/cmake --build /home/art/nordic/peripheral_uart/build

If I disable config log with

CONFIG_LOG=n

it builds but has a high RAM usage:

Memory region         Used Size  Region Size  %age Used
           FLASH:      180084 B       256 KB     68.70%
             RAM:       32288 B        32 KB     98.54%
        IDT_LIST:          0 GB        32 KB      0.00%

My question are:

• Is this the correct controller for my use case? If not, which is?
• Is this the correct sample for my use case? If not, which is?
• Why is the sample available for the nrf52820 but does not build out of the box?
• How can I reduce the footprint while still meeting the requirements, especially FOTA, which is increasing footprint heavily (with

  CONFIG_BOOTLOADER_MCUBOOT=y

  I get

  region `FLASH' overflowed by 78632 bytes

  )

Thanks in advance!

[AHaug]

Hi,

If you wish to do FOTA and have support for BLE and dual bank dfu, then you will need either an external flash or an SoC with more flash.

FOTA DFU requires dual bank, meaning that your application can be maximum the approx size of ~95% of (the total flash available - mcuboot flash) / 2

Example for the nRF52840 with a 48kB MCUboot:

Application size = 95% of (1024kB -48kB) / 2 ~ 465kB (not included setting partitions and other storage partitions). Do note that you can optimize MCUboot to be smaller.

Similar exercise for the 52820 will leave you with an max app size of < 100kB not including settings and custom partitions.

Solution: 

1. Chip with more internal memory
2. External flash
3. Don't do BLE FOTA but use serial recovery and single bank instead (not recommended)
4. See https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/test_and_optimize.html if you are able to reduce the application size to be less than the what I mentioned were the maximum application size

Kind regards,
Andreas

[Artnia]

Hi Andreas,

thanks for clarifying.

Is it possible to port some of the functionalities to the host controller, instead of having them on the nRF52820?

Specifically Serialization (https://docs.nordicsemi.com/bundle/sdk_nrf5_v17.1.0/page/lib_serialization.html) and RPC (https://developer.nordicsemi.com/nRF_Connect_SDK/doc-legacy/latest/nrfxlib/nrf_rpc/README.html) are things that we are considering. I am not quiet sure about the relationship of these two.

• Do you consider using one of them as another solution for our problem?
• Is Serialization part of NRF5 SDK while RPC is part of Connect SDK?
• How do I test their footprint on the nRF52820 as neither Serialization nor RPC is available for the nRF52820?
• The path on my drive is .../ncs/v2.7.0/nrf/samples/nrf_rpc/entropy_nrf53/ while according to the doc (developer.nordicsemi.com/.../README.html it should be samples/nrf_rpc/protocols_serialization/server. Is something broken here?

Thanks.

[AHaug]

Hi,

I see I missed to clarify one of your initial questions:

Why is the sample available for the nrf52820 but does not build out of the box?

The peripheral_uart sample is not supported on the nRF52820. I'm not sure where you've seen that information, but if it is through the "create build configuration" action in the extension, then the answer is that all boards are available for selection if you press "all boards", but not all boards are supported in all samples.

Artnia said:

Is it possible to port some of the functionalities to the host controller, instead of having them on the nRF52820?

This is a bit too vague for me to give you an answer about. Please specify what functionalities you would like to port if you still want an answer for this item

Artnia said:

Do you consider using one of them as another solution for our problem?

Hmm, no I would not say that I consider this a solution for your problem. RCP will cause you to also include OpenThread to your devices, which in turn will require more memory consumption. In addition, OpenThread is not supported for any devices with less than 1MB of internal memory, meaning that any SoC that are smaller in memory than the nRF52840 is not supported.

Artnia said:

How do I test their footprint on the nRF52820 as neither Serialization nor RPC is available for the nRF52820?

As mentioned, OpenThread is not supported for the nRF52820 so if you wish to test this for that SoC, then you will have to add this support on your own. Unfortunately, we won't be able to help you with this.

Artnia said:

The path on my drive is .../ncs/v2.7.0/nrf/samples/nrf_rpc/entropy_nrf53/ while according to the doc (developer.nordicsemi.com/.../README.html it should be samples/nrf_rpc/protocols_serialization/server. Is something broken here?

1) The path in the documentation URL and the repository path may differ some time. The documentation uses different names than the github repo for NCS, which in turn is what you see in the local SDK instance on your computer.

2) You're comparing NCS v2.7.0 path with the NCS-latest documentation. These are not the same thing. From what I can see, the serialization sample will either not be added before the next release of the SDK or it will be restructured and added elsewhere.

Kind regards,
Andreas

[Artnia]

Hi Andreas,

I assume that the peripheral_uart sample is available for the nrf52820 not only because the link you posted says so ("The boards nrf52dk_nrf52810, nrf52840dk_nrf52811, and nrf52833dk_nrf52820 only support the Minimal sample variant.") but also because it is listed under compatible boards in VSC:

Digging deeper in Minimal sample variant the documentation leads to Experimental Bluetooth Low Energy Remote Procedure Call interface. That is why I came up with this idea of using RPC (NOT RCP!). In general we need only a BLE UART Proxy (not OpenThread, etc.) functionality. But as the peripheral_uart sample did not build due to footprint (especially with FOTA requirement) we try to find some other way. This is where we thought about serialization.

Not sure whether I am mixing things up. I am thankful for clarification.

Kind regards,
Artur

[AHaug]

Ah, would you look at that. I was too quick when scanning over the hardware platforms:  

You are right, the 52820 is present in the list of supported devices so it should work. I also see I was to quick when reading "RPC", again, my bad.

I will read to your query once more and look up some information w.r.t this

I'll get back to you before the weekend

Kind regards,
Andreas

[AHaug]

Hi again,

I see now where the confusion occurred. The sample you refer to, which uses the protocol serialization is only using RPC, i.e it is an OpenThread device.

But anyways. As I understand the Remote Procedure call library is in theory something that could work to fix your limited memory issue, but I'm struggling with how to see that this is the best solution. It would require you to split up your code base, create an intrical custom DFU solution and to introduce another Nordic MCU to your project instead of simply choosing a MCU with more memory.

I assume that you're so hesitant w.r.t upgrading the 52820 to an 52840 due to this being a product that is already in the field and/or has a finalized design and that you consider the only solution to be a software fix instead of a hardware upgrade. But if you're still in development it would be easier and less time consuming to swap the SoC that is flash limited in the first place since you're already considering introducing another MCU 

As a disclaimer, it will be up to you, the developer and customer, to design your product and it is none of my business how you decide to do so, but this sounds like a solution that will cause you quite a bit of technical debt as well as an increase in development cost. The general recommendation we give is to start with the largest device in the family of SoC's you're considering using for development, for instance the nRF52840. When you finalized the feature list and see the ROM/RAM and general BoM and see that you can fit your project within a smaller device then first at this point in time consider if you want to downgrade to for instance the nRF52833 with 512kB flash memory and less RAM than the nRF52840.

To summarize, I don't want to recommend you to use RPC with the nRF52820 and a second MCU but you are free to evaluate this solution on your own 

Kind regards,
Andreas