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

[Artnia]

Hi Andreas,

thanks again for the info.

I agree with you, upgrading to e.g. nRF52840 is one way to go. But as the functionality of our use case is pretty simple (just forwarding data from UART to BLE and back) we thought the nRF52820 should be enough.

I still have some questions, not only related to resource optimization but also in general:

1. The peripheral_uart sample contains
   1. BLE controller
   2. BLE host
   3. BLE application
      
      That means that everything related to BLE is inside this controller and it can be used stand alone. If we wanted to have the application part on a different MCU (STM as host) how can we achieve this? Background is having the nRF52820 with the same software (STM with different software) in different products. And different products can have different GATT profiles etc. What is the best way to have this flexible?
2. Serialization/ RPC:
   1. Is it true that while serialization is part of nRF5 SDK, RPC is part of Connect SDK?
   2. Are they both equivalent?
   3. Can both be used to connect the nRF chip to the STM chip?
   4. Can I use RPC only with BLE and not OpenThread etc?
   5. If we decided to go this direction, what do you recommend serialization or RPC?
3. SoftDevice
   1. What is the difference between SoftDevice 112 and SoftDevice 113?
   2. Is the following correct (taken from Comparison nRF5 SDK vs. nRF Connect SDK)?
      
   3. While SoftDevice (i.e. nRF5 SDK and hence not recommended for new designs) can be downloaded from the website, where can I get the equivalent (SoftDevice controller + Zeyphr Bluetooth Host)?
      

In summary the current idea (can change if things get clearer) is to go with the following setup. Is this reasonable?

• nRF52820 without FOTA, only with UART bootloader with small footprint and single bank DFU
• Using serialization/RPC to have the application part on the host side. This way the nRF52820 can be used with same software in different products (GATT profiles etc. are defined in host). This way the nRF52820 would be the "connectivity chip" as described in Serialization.
• Using the latest Connect SDK with VSC integration

[AHaug]

Hi,

Artnia said:

I agree with you, upgrading to e.g. nRF52840 is one way to go. But as the functionality of our use case is pretty simple (just forwarding data from UART to BLE and back) we thought the nRF52820 should be enough.

I agree w.r.t the features: it should be simple enough, but unfortunately not with dual slot DFU in nRF Connect SDK due to how that requires to divide your applicaiton memory into two equal slot. An item that could be worth investigating is LZMA2 compression of the slot that should contain the update image: https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/app_dev/bootloaders_dfu/mcuboot_image_compression.html#mcuboot-image-compression 

Do note that the gain with compression might vary from application to application since the gain is determined by the entropy of the application. So in some cases you might get up to 15% gain and in other cases less.

I'll have to get back to you w.r.t the remaining list of questions later this week since it will require a bit more extensive explanation to answer them in a manner that does not result in too much uncertainty. I'll try to get back to you tomorrow

Kind regards,
Andreas

[AHaug]

Hi again and thank you for your patience

Artnia said:

If we wanted to have the application part on a different MCU (STM as host) how can we achieve this?

Unfortunately we don't have any samples other than the documentation for BLE RPC that you refer to, so if you wish to achieve it you have to follow the set of steps that are listed. You would have to break down the peripheral UART and extract the application.

Artnia said:

What is the best way to have this flexible?

Evaluation of this is unfortunately something that you and your company will have to do.

Artnia said:

• Is it true that while serialization is part of nRF5 SDK, RPC is part of Connect SDK?
• Are they both equivalent?

Yes. But the terminology for serialization is still something that is present in both SDK. 

This is similar to how the SoftDevice and SoftDevice Controller are two similar solutions for two different SDKs.

Artnia said:

Can both be used to connect the nRF chip to the STM chip?

Limitations  and dependencies refer to nrf-rpc as a requirement which states "nRF RPC is a remote procedure call library for enabling inter-processor communication on Nordic Semiconductor SoCs." i,e it states that it is only supported for use with nRF SoCs, i.e nRF + STM is not supported.

Artnia said:

Can I use RPC only with BLE and not OpenThread etc?

Either or AFAK. The nRF RPC: Protocols serialization server sample says: "The Protocols serialization server sample implements the server part of the serialization of OpenThread, Bluetooth LE API and NFC calls between two devices that communicate with each other using the UART interface. The sample uses the Remote procedure call library (nRF RPC) and CBOR encoding to serialize function calls."

Artnia said:

If we decided to go this direction, what do you recommend serialization or RPC?

I'm not familiar enough with either to make any recommendations and the evaluation is something that you and your company needs to make.

Artnia said:

What is the difference between SoftDevice 112 and SoftDevice 113?

You can read more about the SoftDevices here https://docs.nordicsemi.com/bundle/sdk_nrf5_v17.1.0/page/index.html. I'm sure you're aware of this, but as a disclaimer SoftDevice 112 and 113 are for nRF5 SDK only, while the SoftDevice Controller is for nRF Connect SDK.

Artnia said:

While SoftDevice (i.e. nRF5 SDK and hence not recommended for new designs) can be downloaded from the website, where can I get the equivalent (SoftDevice controller + Zeyphr Bluetooth Host)?

This has changed between nRF5 SDK and nRF Connect SDK, where in the previous instance the SoftDevices were designed to be more or less suitable depending on the type of device you were using as well as w.r.t how many features you needed. I.e the smaller SoftDevices had less features and required less memory footprint.

In nRF Connect SDK the controller and host are included when you enable the configurations and built and included from there. They are not distributed as hexes as the SoftDevices were.

Comments to this as standalones:

Artnia said:

nRF52820 without FOTA, only with UART bootloader with small footprint and single bank DFU

This is reasonable and that you do serial recovery DFU over UART for cases where you need to update the 52820

Artnia said:

Using serialization/RPC to have the application part on the host side. This way the nRF52820 can be used with same software in different products (GATT profiles etc. are defined in host). This way the nRF52820 would be the "connectivity chip" as described in Serialization.

Only inter communication with nRF SoCs + a disclaimer that you will have to validate the working theory yourself

Artnia said:

Using the latest Connect SDK with VSC integration

You will struggle with adding DFU support with the exception of serial recovery over UART

Comments to all three items together:

Same as the comments w.r.t the individual items, but with the addition that Serialization in terms of the link you've added is only for nRF5 SDK and not supported in nRF Connect SDK

Kind regards,
Andreas

[Artnia]

Hi Andreas,

thank you very much for the reply - it clarified a lot!

Now the next step: I want to use the peripheral_uart sample as a base. For the nRF52820 it builds in the minimal config.

Also when adding the serial recovery (single bank bootloader) via UART it fits. Following the dfu-over-uart tutorial I managed to update the app using mcumgr from PC to nRF. The next step is to do the same thing but this time replacing the PC by the ST as host. I read the docs/devzone (device_mgmt/dfu, zephyr-mcumgr-client, dfu_target, central_smp_client_dfu, etc) but I am not sure how to solve this best.

So my question is: How do I do UART DFU from another controller (ST) as a host to update the nRF52820?

Thanks!

Edit: I want to go with NCS not NRF5.