• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 56 subscribers
  • Views 276 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

CC2538: TI Zigbee Linux Gateway Permit Join is always False

Haines Todd
Prodigy 10 points
Part Number: CC2538
Other Parts Discussed in Thread: CC2531, Z-STACK,

Context, I have a custom board with a CC2538 connected via USB to a single board computer running yocto linux. All dependencies (protobuf) are installed and the TI Linux Gateway applications as well as the demo app compile and run.

The CC2538 is running the following firmware:
/ti/Zigbee_3_0_Linux_Gateway_1_0_1/Firmware/znp/CC2538_GW_ZNP_EM_StandAlone_USB.hex

It can be found at the path /dev/ttyACM0 with the following firmware version

```
root:tools# ./gw_soc_fw_version_query.bin /dev/ttyACM0
Using serial port: /dev/ttyACM0
Received System version.
Transport Protocol Version: 2
Product ID: 0
Software Release: 2.7.2
Software Revision: 0
(Revision not specified)
```

I have modified the NPI_Gateway.cfg to have this device path and config.ini to set PERMIT_JOIN to 1 and and PAN ID to 0x1337.

Everything in the demo app and other apps looks fine, but when I press 'P' in the demo app to permit joining, none of my router device join the network.

So I setup a CC2531 USB dongle as a packet sniffer and have it watching the same channel, and this is what all of the beacons from my CC2538 look like.

It looks like a smoking gun that Association Permit is always False, even when the beacon is sent seconds after I pressed 'P' in the demo app to permit joining and have PERMIT_JOIN=1 in config.ini.

At first, I thought the issue was key and security, or perhaps the devices were on different channel, or the PAN ID was set wrong somewhere. But this problem is stopping everything right out of the gate.

The demo app and TI stack is very complex, I'm not sure where to look from here on what needs to be changed to force Permit Join to be on.

  • 0
    TI__Guru**** 205697 points

    Hi Haines,

    Please first confirm that you have followed all steps in the Zigbee_3_0_Linux_Gateway_1_0_1\Documents\Z-Stack Linux Gateway - Quick Start Guide & User's Guide.  Everything appears to be correct from the Local Gateway Sample Application screen and log.  You can even observe the [send] 05:25:36:02:00:00:3C:01 returns [SRSP] 01:65:36:00 which is the expectation for the ZDO_MGMT_PERMIT_JOIN_REQ Monitor and Test API.  This could be an issue with the CC2538 firmware or device.  What CC2538 package are you using and do you ever test with a CC2538EMK?  Are you making sure to erase all device memory before programming the ZNP firmware?  Try to see if you can use Z-Tool to form a Zigbee network and join devices with the existing ZNP firmware and custom board, here are blog instructions from a community member.

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Prodigy 10 points

    Thank you for the suggestions, I made some progress.

    This board uses the CC2538SF53RTQT. 

    I have not used the CC2538EMK. Some early development was done using the same single board computer (on a dev carrier board) and the CC2531 USB dongle. Though, the layout for the CC2538 we use is based on the CC2538EMK's layout from here.
    https://www.ti.com/lit/df/tidr187/tidr187.pdf?ts=1712675466113

    Now for the progress.

    I re-flashed the CC2538 with the same ZNP hex file and then restarted the TI linux gateway and demo app. After pressing 'P' on the demo app I was overjoyed to see my router device (and xbee 3) join my CC2538's network.

    After looking through the sniffer logs, I could see that the Association Permit bit in the beacon was True for an instant, which ultimately allowed my xbee to join. The key exchange went smoothly after that and I got link status updates for several minutes afterward.

    Then, without changing anything, I removed the xbee router from the network, restarted everything and tried to replicate the process. It failed again...
    Ever since then, I have only seen Association Permit be False.

    So I continued my troubleshooting and have more observations that I think confirm your suspicion that the root cause has to do with the firmware on the CC2538.

    Another Weird Thing I have Seen

    In config.ini, when I change the PAN ID, (for example from 0x1337 to 0x1338). The demo app always shows the PAN ID as 0x1337, even after rebooting the CC2538 and my single board computer.

    The only way to change the PAN ID is to completely reflash the CC2538 and then run the TI Linxux Zigbee Stack. After that though, I can't change it, unless I reflash the CC2538 again.

    This implies there is some non-volatile memory in the CC2538 other than the program ROM that is getting stuck at certain values (hence reflashing it is the only way to change it). 

    This seems related to my Association Permit issue. I could imagine there is a variable stored in non-volatile memory that is causing Permit Join to get stuck at 0, no matter what commands the TI Linux Zigbee Stack sends.

    My Options

    There are two ways I can think of to get around this issue:

    1. recompile the ZNP source code with a version that does not use non-volatile memory. (I'm fine with everything starting from a clean slate after each power cycle. I have never worked with the ZNP source code though and don't even have TI's IDE installed, so this opens up a lot more development risk for me.

    2. Use some sort of command in the TI Linux Zigbee Stack that resets everything in the CC2538 non-volatile memory. If Z-tool ran in linux, I could experiment with the API to see if such a command exists, but its much more daunting without Z-tool. I can't easily connect the USB signals of my board to a windows machine to use Z-tool there.

  • +1 in reply to Haines Todd
    TI__Guru**** 205697 points
    Haines Todd said:
    This implies there is some non-volatile memory in the CC2538 other than the program ROM that is getting stuck at certain values (hence reflashing it is the only way to change it). 

    I think you're correct, and "restarting everything" is causing inconsistent non-volatile (NV) flash settings between the CC2538 ZNP device and Linux host.

    1. This would require you to download Z-STACK 3.0.2 and build the \Projects\zstack\ZNP\CC2538 application in IAR EWARM 8.22.1 with NV_RESTORE removed from znp.cfg

    2. SYS_OSAL_NV_WRITE with id 0x03 (ZCD_NV_STARTUP_OPTION) and value 0x03 followed by a SYS_RESET type 0x00 would clear the CC2538 ZNP NV memory.  This is further detailed in the links I provided earlier.  You can modify znp_misc.c osal_nv_write and znpReset usage to accomplish your needs.

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Prodigy 10 points

    Thank you very much, your advice on 1. did it for me.

    I modified znpReset in znp_misc.c always do a hard reset and clear the non-volatile memory (hackish but I will try a less aggressive approach later).

    Then I modified osal_zstack_server_znp.c to call znpReset(1,1,0) right before the call to zspbInit(taskID++)

    I must have broken something in the demo app because the paired xbee router no longer appears in the device list; however, I can see that it has joined the network based on its own Association Indication and the traffic my sniffer is capturing. (I won't need the demo app long term anyways).

    I'm sure there will be other difficulties, but this solves the immediate issue I encountered.

    Also for any future viewers readers googling for how to join an Xbee 3 (or similar xbee running the full zigbee stack) to a TI coordinator, these are the AT settings to use on the Xbee.

    https://www.digi.com/support/knowledge-base/zigbee-home-automation

    The most important one is having ZS=2.

    Also the Pan ID of the xbee should be set to your TI Coordinator's EXTPANID in reverse endianess

    So for me:

    Means I need to set my ID param in the xbee to the following:

    Or just set ID=0 and allow the Xbee to join any network, then check the OP AT parameter to see what the operating PAN ID is.