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]

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.

[AHaug]

Artnia said:

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

Glad to hear that! 

Instead of the unofficial central_smp_client_dfu solution you can look at the official sample here https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/samples/bluetooth/central_smp_client/README.html 

Artnia said:

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

Unfortunately we generally don't give support to non-Nordic products so for anything involving the ST I can't help you with.

A generic solution for generic mcus is that you will have to create your own firmware for the ST solution that mimics the central_smp_client (or add board support for the NCS sample) to receive the image. Then send a signal to the nrf52820 that it should enter bootloader mode for DFU procedure then distribute the image to the nrf52820 with serial recovery over UART. This will require you to write your own, custom, proprietary code for both app and bootloader that handles this.

Kind regards,
Andreas

[Artnia]

Hi Andreas,

the link you provided is for BLE and states "This sample does not provide the means to program a device using DFU. It demonstrates the communication between SMP Client and SMP Server."

But what I need is UART DFU. Is the link still relevant in this case?

What if the ST was an nRF? How would the solution then look like?

[AHaug]

Hi,

Artnia said:

read the docs/devzone (device_mgmt/dfu, zephyr-mcumgr-client, dfu_target, central_smp_client_dfu,

The central_smp_client_dfu sample you refer to here is also for BLE, but it's unofficial and the implementation is not recommended to follow which is why I referred you to the official sample instead.

Artnia said:

But what I need is UART DFU. Is the link still relevant in this case?

The idea behind distributing the image between the server and client will be the same with the exception of the transport and the slot that you write the image to (For dual slot it is the secondary app slot, for serial recovery you instead overwrite the app in the primary app slot).

Artnia said:

What if the ST was an nRF? How would the solution then look like?

In this case you can use RPC since it's supported for intercommunication between nRF SoCs (or CPUs on the same SoC) as mentioned here: https://developer.nordicsemi.com/nRF_Connect_SDK/doc-legacy/latest/nrfxlib/nrf_rpc/README.html#nrf-rpc 

The generic solution will still look the same.

Kind regards,
Andreas