• State Not Answered
  • Replies 13 replies
  • Subscribers 68 subscribers
  • Views 444 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 334788
Options

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!

  • 0 in reply to Artnia
    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

  • 0 in reply to AHaug

    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?

  • 0 in reply to Artnia

    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

Related