TI PySpinel fails to work in a BeaglePlay Linux host

Part Number: LP-CC1352P7
Other Parts Discussed in Thread: WI-SUN, CC1352P7, CC1352R, LPSTK-CC1352R, UNIFLASH

Tool/software:

Dear TI Engineers,

I have set up a Wi-SUN network which is composed of:

  1. a BeaglePlay installed with BeaglePlay Debian minimal OS 11.8.
  2. Beagleplay on-board CC1352P7 flashed with the border router firmware
  3. a Launchpad CC1352P7 flashed with the Coap router node offchip OAD firmware.
  4. a Launchpad CC1352R flashed with the router node firmware.
  5. LPSTK-CC1352R LaunchPad SensorTag flashed as router node.

Then, I downloaded this script and set up my Ti Spinel environment:

https://github.com/TexasInstruments/simplelink-lowpower-f2-sdk/blob/main/tools/ti_wisunfan/setup_pyspinel.sh

However, this is the result which I received from the command prompt on a terminal on the Beagleplay host

spinel-cli > connecteddevices
List of connected devices currently in routing table:
2020:abcd::212:4b00:1cbc:33c1
2020:abcd::212:4b00:14f9:675c
2020:abcd::212:4b00:1ca7:6343
Number of connected devices: 3
Done
spinel-cli > ifconfig
up
Done
spinel-cli > wisunstack
start
Done
spinel-cli > getoadfwver 2020:acd::212:400:14f9:675c
Sending OAD firmware version request message
spinel-cli > Invalid coap option base URI

CoAP packet received from 2020:abcd::212:4b00:29c4:b348: type: 0 (Confirmable), token: 10506430468262651724, code: 0.01 (Get), msg_id: 0
No CoAP payload

spinel-cli > ifconfig
up
Done
spinel-cli > wisunstack
start
Done
spinel-cli > dodagroute 2020:acd::212:400:14f9:675c
Error: Could not retrieve dodag route to selected embedded device
spinel-cli > ifconfig
Done
spinel-cli > wisunstack
Error
spinel-cli >

TI Spinel malfunctions. It fails to detect the coap node.  Furthermore, Spinel hung up after it had failed to detect coap node.

Please help me to correct them.

In order to confirm 675c is the coap node, I restarted my Beagleplay and started the web app.  It confirmed that 675c is the coap node.

  • Hi Tim,

    That's interesting. Can you confirm the coap node is responsive when this happens, e.g. check the uart display?

    Which SW version are you using?

    Cheers,

    Marie H

  • Yes,

    67c5 is a healthy node.  I even tested it today over 100m and it responded to LEDs control at once.

    debian@BeaglePlay:~$ ping6 -I wfan0 -a -c 10 2020:abcd:0000:0000:0212:4b00:14f9:675c
    PING 2020:abcd:0000:0000:0212:4b00:14f9:675c(2020:abcd::212:4b00:14f9:675c) from 2020:abcd::212:4b00:29c4:b348 wfan0: 56 data bytes
    64 bytes from 2020:abcd::212:4b00:14f9:675c: icmp_seq=1 ttl=64 time=168 ms
    64 bytes from 2020:abcd::212:4b00:14f9:675c: icmp_seq=2 ttl=64 time=192 ms
    64 bytes from 2020:abcd::212:4b00:14f9:675c: icmp_seq=3 ttl=64 time=176 ms
    64 bytes from 2020:abcd::212:4b00:14f9:675c: icmp_seq=4 ttl=64 time=223 ms
    64 bytes from 2020:abcd::212:4b00:14f9:675c: icmp_seq=5 ttl=64 time=197 ms
    64 bytes from 2020:abcd::212:4b00:14f9:675c: icmp_seq=6 ttl=64 time=525 ms
    64 bytes from 2020:abcd::212:4b00:14f9:675c: icmp_seq=7 ttl=64 time=326 ms
    64 bytes from 2020:abcd::212:4b00:14f9:675c: icmp_seq=8 ttl=64 time=289 ms
    64 bytes from 2020:abcd::212:4b00:14f9:675c: icmp_seq=9 ttl=64 time=353 ms
    64 bytes from 2020:abcd::212:4b00:14f9:675c: icmp_seq=10 ttl=64 time=293 ms
    
    --- 2020:abcd:0000:0000:0212:4b00:14f9:675c ping statistics ---
    10 packets transmitted, 10 received, 0% packet loss, time 9013ms
    rtt min/avg/max/mdev = 168.054/274.081/524.851/104.227 ms

  • I rebuilt my firmware to SimpleLink CC13xx CC26xx SDK (7.41.00.17).

    TI Spinel as shown in the link above.

  • I suspect the current TI Spinel is the culprit.

  • I just tested in again with TI Spinel.  Here are the output:

    spinel-cli > ping 2020:acd::212:400:14f9:675c
    
    Echo request: 56 bytes from 2020:abcd::212:4b00:29c4:b348 to 2020:acd::212:400:14f9:675c, icmp_seq=43339 hlim=63. Sending echo response.
    
    56 bytes from 2020:acd::212:400:14f9:675c: icmp_seq=43339 hlim=64 time=77ms
    
    spinel-cli > ping 2020:acd::212:400:14f9:675c
    
    Echo request: 56 bytes from 2020:abcd::212:4b00:29c4:b348 to 2020:acd::212:400:14f9:675c, icmp_seq=52154 hlim=63. Sending echo response.
    
    56 bytes from 2020:acd::212:400:14f9:675c: icmp_seq=52154 hlim=64 time=76ms
    
    spinel-cli > getoadfwver 2020:acd::212:400:14f9:675c
    
    Sending OAD firmware version request message
    spinel-cli > Invalid coap option base URI
    
    CoAP packet received from 2020:abcd::212:4b00:29c4:b348: type: 0 (Confirmable), token: 5045087140684770527, code: 0.01 (Get), msg_id: 0
    No CoAP payload
    

  • Hello Marie,

    TI Spinel is very ill.  Even if it cannot detect coap firmware, it should not have hung up.  Please repair it as soon as possible.

    I need to do a remote Over-The-Air firmware update on a 100m target away.

  • Hi Tim,

    "Invalid coap option base URI" is returned when the message received from the node has no registered URI. It expects in this case the URI: OAD_FWV_RESP. Can you check which URI is used for your command?

    Cheers,

    Marie H

  • What is "OAD_FWV_RESP"?  How do I set it?

  • Is it an option in the OTA router node CCS project?

  • Marie,

    I created a new CCS project for the MCUboot.  It turned out to be a failed compilation:

    My software is CCS 12.8.1 for Windows, SimpleLink CC13xx CC26xx SDK (7.41.00.17)

    Board is CC1352P7-1 Launchpad

    Please show me how to repair it.

  • Hello Marie,

    Could you please repair all these problems reported by me?Disappointed

  • I compiled a new mcuboot + offchip oad project based on the the SDK 7.40.  The MCUboot project could be compiled successfully.

    Yet, OAD firmware check still failed.

    Also, the newer SDK 7.41 limits the PAN ID assignment of the router node.  It seems like a design fault because we can programme the router node to limit its access to certain sub network under the same Network Name.

  • I have compiled the mcuboot project by adding this line in the project's search paths:

    ${COM_TI_SIMPLELINK_CC13XX_CC26XX_SDK_INSTALL_DIR}/source/ti/common/flash/no_rtos/extFlash/

    However, the whole (mcuboot + offchip oad) turned out to be a complete failure based on SDK7.41.0.17.  I created the projects and then flashed them using UniFlash.

    The final Launchpad 1352p7-1 could not join my border router any more.  The red LED even did not blink.

    Please repair it at once.

  • Hi Tim,

    The PAN ID variable on the router node side didn't do anything, that's why we removed it.

    Cheers,

    Marie H

  • Hi Tim,

    Whenever you erase the flash on the node side, please also erase the flash and reprogram the BR. This is to avoid a situation where one device has outdated bonding information in flash.

    Cheers,

    Marie H

  • okay, let me reprogramme all my network nodes under the newest SDK and see how they work.

    Merry Christmas and Happy New Year! Santa

  • Hello Marie,

    Assuming we have an existing working TI Wi-SUN network,

    1. how does TI Wi-SUN stack handle a newly added coap router node which requires OTA firmware updating?
    2. Do we have to reprogramme the border router?  Please clarify.  It is a very crucial point!  Fearful
  • Hi Tim,

    1. You can perform OTA within the Wi-SUN Network. We have a SimpleLink Academy lab which walks you through the process:

    https://dev.ti.com/tirex/explore/node?a=BSEc4rl__6.30.00.84&node=A__AZzPlMOhME2Ek7DI7BJuCA__com.ti.SIMPLELINK_ACADEMY_CC13XX_CC26XX_SDK__AfkT0vQ__LATEST&placeholder=true

    2. Not sure what you mean. The BR supports OTA out of the box.

    Cheers,

    Marie H

  • I already did an OTA firmware upload test successfully half year ago in 2024.

    The present issue is with your very ill TI Spinel which hung up when I tried to do a OTA firmware updating the coap node.

    You even request me to reprogram my border router which should be in production and cannot be reprogrammed.

    So the whole picture provided by you is self-contradictory.

  • Hi Tim,

    To clarify: If you erase the NV information in flash on the node side, you should do the same on the BR side. You do not need to do this after upgrading the firmware of the node with an OTA.

    Cheers,

    Marie H

  • Hi Marie,

    Then, what exactly is "NV information" in flash on the node side?

  • Hi Tim,

    Non volatile, i.e. flash, When a node joins a Wi-SUN network it will store network information in NV. When the authentication process has completed it will store security information (notably network keys) in NV. If the BR thinks it's connecting to a new device, while the node thinks it's connecting to a familiar network, they will approach the join process at different stages and this will in most cases lead to a situation where the node is not able to join the network.

    Cheers,

    Marie H