This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

LPSTK-CC1352R: Border Router Problem

Part Number: LPSTK-CC1352R
Other Parts Discussed in Thread: CC1352R, LAUNCHXL-CC1352P, BEAGLE-3P-BBONE-AI, TIDEP0084

 getting following error: RCP is missing required capabilities: tx-security tx-timing when looking at RPi Log. 

pi_raspberrypi:~ $ sudo otbr-agent -d 7 -v spinel+hdlc+uart:///dev/ttyACM0 -I wpan0
otbr-agent[12148]: [INFO]-UTILS---: Running 0.3.0-f543024
otbr-agent[12148]: [INFO]-UTILS---: Thread version: 1.2.0
otbr-agent[12148]: [INFO]-UTILS---: Thread interface: wpan0
otbr-agent[12148]: [INFO]-UTILS---: Backbone interface:
otbr-agent[12148]: [INFO]-UTILS---: Radio URL: spinel+hdlc+uart:///dev/ttyACM0
otbr-agent[12148]: [INFO]-PLAT----: RCP reset: RESET_SOFTWARE
otbr-agent[12148]: [NOTE]-PLAT----: RCP API Version: 4
otbr-agent[12148]: [CRIT]-PLAT----: RCP is missing required capabilities: tx-security tx-timing
otbr-agent[12148]: [CRIT]-PLAT----: CheckRadioCapabilities() at ../../third_party/openthread/repo/src/lib/spinel/radio_spinel_impl.hpp:382: RadioSpinelIncompatible

I build cc1352  rcp flash file with following commands:

docker pull openthread/environment:latest
docker run -it --rm openthread/environment bash
cd ot-cc13x2-cc26x2
git submodule update --init
./script/bootstrap
./script/build -DTI_PLATFORM=cc1352
And RPi border router with following descrpition:
I was trying RCP, NCP, CLI flashes but without success.  Could you please give me any advice how to make it working?
  • Do you use LPSTK-CC1352R as RCP? If so, it shouldn't simulate ttyACM0 on your Raspberry Pi. How do you connect LPSTK-CC1352R to your Raspberry Pi?

  • In our configuration LPSTK cc1352r is connected to LAUNCHXL-CC1352P  via JTAG and 2 additional TX/RX wires like on pictures below

    Launchpad is connected to RPi with USB cable.

    When I upload  FTD_CLI  flash  I can  connect   with thread CLI on RPi  with use

    sudo minicom -D /dev/ttyACM0 -b 115200

    Unfortunatelly If I switch to  RCP flash prepared like decribed above I got problem in log like mentioned above and otbr-agent restarting  in cycle. 

  • Hi,

    When I upload  FTD_CLI  flash  I can  connect   with thread CLI on RPi  with use

    sudo minicom -D /dev/ttyACM0 -b 115200

    The connections look good to me, and this seems to confirm that it is working (can interact with CLI successfuly via serial).

    otbr-agent[12148]: [CRIT]-PLAT----: RCP is missing required capabilities: tx-security tx-timing

    These capabilities, tx-security and tx-timing, were introduced to support CSL feature (https://github.com/openthread/openthread/blame/961fd9ae955fc6992953224bc53a6d3644ba715d/src/lib/spinel/radio_spinel_impl.hpp#L375).

    Is this a feature needed for your use-case?
    If not, you could revert to a pre-CSL commit of ot-br-posix.

    We also have this, which might be useful: https://dev.ti.com/tirex/explore/node?node=ABSaAO-k3rswvnB7RdRtww__pTTHBmu__LATEST

    Thanks,

    Toby

  • Your advice was very very very valuable - thank you. As I would like to help other people also below please find what was final sotution.
    How I connect CC1352 you see in post above ( LPSTK cc1352r is connected to LAUNCHXL-CC1352P  via JTAG and 2 additional TX/RX wires like on pictures below. No battery or external power supply needed - all powered from USB).


    For making flash for CC1352  without CSL

    Install docker

    docker pull openthread/environment:latest
    docker run -it --rm openthread/environment bash
    git clone github.com/.../ot-cc13x2-cc26x2.git
    cd ot-cc13x2-cc26x2
    git submodule update --init
    cd openthread
    git reset 31c7208ac87768f8fe7ad4c94d8e8b184bb0ee51
    ./script/bootstrap
    ./script/build -DTI_PLATFORM=cc1352

    Then on border router I advice to compile ot-br-posix like below:

    #in case you have previous compilation remove folder and clone new repo like described

    rm -r ot-br-posix     

    git clone ---recursive  https://github.com/openthread/ot-br-posix.git

    git submodule update --init --recursive

    then

    To use OTBR in Thread 1.1 please add  to third_party/openthread/CMakeLists.txt following line

    set(OT_THREAD_VERSION 1.1 CACHE STRING "Thread 1.1" FORCE)
    cd oot-br-posix
    ./script/bootstrap 

    BACKBONE_ROUTER=0 INFRA_IF_NAME=wlan0 ./script/setup

    then

    Below checks/task  form website: OpenThread Border Router Build and Configuration

    Configure the RCP device's serial port in otbr-agent:

    1. Determine the serial port name for the RCP device by checking /dev:
      ls /dev/tty*
    2. Append this to /etc/default/otbr-agent. For example, for a serial port name of ttyACM0:
      OTBR_AGENT_OPTS="-I wpan0 spinel+hdlc+uart:///dev/ttyACM0"





    Verify services

    Verify that all required services are enabled:

    sudo systemctl status

    If the setup script was successful, the following services appear in the output:

    • avahi-daemon.service
    • otbr-agent.service
    • otbr-web.service

      Verify RCP

      Verify that the RCP is in the correct state:

      sudo ot-ctl state

      ot-ctl is a command line utility provided with OTBR. It is used to communicate with the Thread PAN interface (default is wpan0) that otbr-agent is bound to in the RCP design.

      If the RCP is successfully running and the node is not a member of a Thread network, the output should be similar to the below:

      disabled

      If the output is OpenThread daemon is not running, troubleshoot with the following:

      1. Verify the Border Router has sufficient power (use the proper external AC adapter).
      2. Disconnect and reconnect the RCP board to the Border Router platform.
      3. Verify that the RCP serial device is present. For example, if the device should be attached to /dev/ttyUSB0:
        ls /dev/tty* /dev/ttyUSB0
      4. Reset the RCP with sudo ot-ctl reset.

      Check the RCP status again with sudo ot-ctl state

      Then you can configure your thread as described

      http://software-dl.ti.com/simplelink/esd/simplelink_cc26x2_sdk/2.10.00.44/exports/examples/rtos/CC26X2R1_LAUNCHXL/thread/cli_ftd/README.html

      pi@raspberrypi:~ $ sudo ot-ctl state
      disabled
      Done
      pi@raspberrypi:~ $ sudo ot-ctl reset
      pi@raspberrypi:~ $ sudo ot-ctl state
      disabled
      Done
      pi@raspberrypi:~ $ sudo ot-ctl channel 14
      Done
      pi@raspberrypi:~ $ sudo ot-ctl panid 0xface
      Done
      pi@raspberrypi:~ $ sudo ot-ctl ifconfig up
      Done
      pi@raspberrypi:~ $ sudo ot-ctl thread start
      Done
      pi@raspberrypi:~ $ sudo ot-ctl state
      leader
      Done

      ----

      So this is advice for people which are willing to work with Thread 1.1  in RCP   architecture  and with CC1352 which not support CSL.

      Do you have any advice how to make it working with Thread 1.2 and CC1352 supporting CSL on hardware architecture which I mention above?

    1. A good portion of the CSL is handled within openthread.

      This code will call some of the (new) platform radio functions (compare the radio.h files between CSL (e.g. master branch) and non-CSL (see <TI SDK>/source/third_party/openthread/include/openthread/platform/radio.h).

      In summary, implementations of these functions must exist in radio.c of the TI examples (e.g. <CCS workspace>/<cli_ftd>/platform/radio.c).

    2. Thank you for your advice - but anyway I need to ask you few more questions.  We are workning on project where in first batch there should be about 70000 flats equipped with sensors and boarder routers. Currently we are more focus on end devices as initially Apple TV set top boxes are planned to be used as border routers. Anyway If you can recommend what in your opinion would be the best platform for cost effecive border router having wifi, ehternet and openthread. We would like use one vendor hardware solution to avoid any incompatibilities. Initially I was thinking about TIDEP0084 and BEAGLE-3P-BBONE-AI. Can you recommend me what platform would be better for mass market (maybe other not mentioned)?

      Can you confirm to me that CC1352 can support Thread 1.2 with CSL?
      Is there is any roadmap for CC1352 with information what thread software releases will be supported and for how long?

    3. Thanks for sharing some details of your respective use-case.

      I do think it makes sense to focus on end devices, since the long-term vision of Thread tends for Border Routers to be as common as Wi-Fi routers.
      With that being said, the timeline for "long-term" is not defined, and may not match your project's timeline (also, I cannot comment on the timeline for Apple set top boxes to enable Thread Border Router).

      Although TIDEP0084 is based on 802.15.4 (similar to Thread), the upper layer of that TID is 15.4-stack. For 15.4 linux gateway, I would actually recommend this instead: https://www.ti.com/tool/TI-15.4-STACK-GATEWAY-LINUX-SDK

      This is a useful design for sensor-to-cloud use cases, however it requires the presence of the gateway (e.g. BeagleBone + 15.4 radio).
      Since your use-case involves many sensors across buildings, the sub1-GHz frequency band of 15.4 stack can improve performance (for range and wall penetration). If you are interested in an intermediate, mid/near term solution, the 15.4-stack linux gateway could be a good option.

      Can you confirm to me that CC1352 can support Thread 1.2 with CSL?
      Is there is any roadmap for CC1352 with information what thread software releases will be supported and for how long?

      Further development is required for Thread 1.2 as I mentioned before; I currently do not have a timeline for this. BUT with that said:
      Note that Thread 1.2 is backwards compatible with Thread 1.1 (please refer to FAQ section here: https://www.threadgroup.org/support#:~:text=Thread%201.2%20adds%20sophisticated%20new,%2Dscale%2C%20professionally%20managed%20network.&text=Devices%20and%20networks%20can%20be,of%20devices%20across%20multiple%20subnets.)