Using the nrf52820 as BLE proxy to UART/SPI

RE: Using the nrf52820 as BLE proxy to UART/SPI

AHaug — Tue, 12 Nov 2024 10:05:23 GMT

Hi,

[quote user="Artnia"] read the docs/devzone (device_mgmt/dfu, zephyr-mcumgr-client, dfu_target, central_smp_client_dfu,[/quote]

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.

[quote user="Artnia"]But what I need is UART DFU. Is the link still relevant in this case?[/quote]

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).

[quote user="Artnia"]What if the ST was an nRF? How would the solution then look like?[/quote]

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

RE: Using the nrf52820 as BLE proxy to UART/SPI

Artnia — Mon, 11 Nov 2024 15:01:03 GMT

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?

RE: Using the nrf52820 as BLE proxy to UART/SPI

AHaug — Fri, 08 Nov 2024 09:39:10 GMT

[quote user="Artnia"]thank you very much for the reply - it clarified a lot![/quote]

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

[quote user="Artnia"]So my question is: How do I do UART DFU from another controller (ST) as a host to update the nRF52820?[/quote]

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

RE: Using the nrf52820 as BLE proxy to UART/SPI

Artnia — Thu, 07 Nov 2024 13:19:36 GMT

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.

RE: Using the nrf52820 as BLE proxy to UART/SPI

AHaug — Fri, 01 Nov 2024 13:44:22 GMT

Hi again and thank you for your patience

[quote user="Artnia"]If we wanted to have the application part on a different MCU (STM as host) how can we achieve this?[/quote]

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.

[quote user="Artnia"]What is the best way to have this flexible?[/quote]

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

[quote user="Artnia"]

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

[/quote]

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.

[quote user="Artnia"]Can both be used to connect the nRF chip to the STM chip?[/quote]

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.

[quote user="Artnia"]Can I use RPC only with BLE and not OpenThread etc?[/quote]

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."

[quote user="Artnia"]If we decided to go this direction, what do you recommend serialization or RPC?[/quote]

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

[quote user="Artnia"]What is the difference between SoftDevice 112 and SoftDevice 113?[/quote]

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.

[quote user="Artnia"]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)?[/quote]

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:

[quote user="Artnia"]nRF52820 without FOTA, only with UART bootloader with small footprint and single bank DFU[/quote]

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

[quote user="Artnia"]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.[/quote]

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

[quote user="Artnia"]Using the latest Connect SDK with VSC integration[/quote]

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

RE: Using the nrf52820 as BLE proxy to UART/SPI

AHaug — Tue, 29 Oct 2024 14:35:02 GMT

Hi,

[quote user="Artnia"]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.[/quote]

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

RE: Using the nrf52820 as BLE proxy to UART/SPI

Artnia — Mon, 28 Oct 2024 14:57:15 GMT

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:

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?
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?
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

RE: Using the nrf52820 as BLE proxy to UART/SPI

AHaug — Fri, 25 Oct 2024 12:26:03 GMT

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

RE: Using the nrf52820 as BLE proxy to UART/SPI

AHaug — Thu, 24 Oct 2024 13:27:43 GMT

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

RE: Using the nrf52820 as BLE proxy to UART/SPI

Artnia — Thu, 24 Oct 2024 12:55:48 GMT

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

RE: Using the nrf52820 as BLE proxy to UART/SPI

AHaug — Thu, 24 Oct 2024 08:28:41 GMT

Hi,

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

[quote user=""]Why is the sample available for the nrf52820 but does not build out of the box?[/quote]

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.

[quote user="Artnia"]Is it possible to port some of the functionalities to the host controller, instead of having them on the nRF52820?[/quote]

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

[quote user="Artnia"]Do you consider using one of them as another solution for our problem?[/quote]

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.

[quote user="Artnia"]How do I test their footprint on the nRF52820 as neither Serialization nor RPC is available for the nRF52820?[/quote]

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.

[quote user="Artnia"]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?[/quote]

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

RE: Using the nrf52820 as BLE proxy to UART/SPI

Artnia — Wed, 23 Oct 2024 20:48:29 GMT

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.

RE: Using the nrf52820 as BLE proxy to UART/SPI

AHaug — Mon, 21 Oct 2024 12:46:05 GMT

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:

Chip with more internal memory
External flash
Don't do BLE FOTA but use serial recovery and single bank instead (not recommended)
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