• State Resolved
  • Locked Locked
  • Replies 18 replies
  • Subscribers 56 subscribers
  • Views 1361 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.

Linux/CC2531: ZED not joining network, following documented procedures

Julien Le Guen
Prodigy 120 points
Part Number: CC2531
Other Parts Discussed in Thread: Z-STACK

Tool/software: Linux

Hi,

I'm trying to interface a CC2531 through ZNP, using the latest Z-Stack firmware to act as a Zigbee End Device.

I'm experiencing an issue while trying to connect to the network:

- I have a Coordinator which advertises on channel 20, permit join, no security, I see the frames every 15 seconds.
- The ZED initiates a Beacon Request that I see on the packet sniffer
- The ZC responds with a Beacon Response that I see on the packet sniffer

But after that the ZED stays indefinitely in state "DEV_NWK_DISC" and I don't get any other ZDO_STATE_CHANGE_IND.

To initiate the network connection on the ZED I'm following these steps from the documentation:

1- Use ZB_WRITE_CONFIGURATION to set ZCD_NV_STARTUP_OPTION to forget existing networks (0x03)
2- Use ZB_WRITE_CONFIGURATION to set
    - ZCD_NV_LOGICAL_TYPE (0x02, device), 
    - ZCD_NV_PAN_ID (0xffff, use any PAN ID),
    - ZCD_NV_CHANLIST (0x00100000 - channel 20 or 0x14)
3- Use AF_REGISTER to register an application (profile HA, one endpoint)
4- Call ZDO_STARTUP_FROM_APP

According to the documentation I should see sereval ZDO_STATE_CHANGE_IND on my end after step 4, but on see one and the device stays in 'DEV_NWK_DISC' state (from UTIL_GET_DEVICE_INFO)

Do you know what could cause this to stall ?

Thanks,
Julien

  • 0
    TI__Mastermind 33640 points

    Hi,

    If possible please share sniffer logs.

    I assume you're using the firmware from Z-Stack Linux Gateway?
    Have you tried joining the ZNP to a coordinator that has security enabled?

    As mentioned in Zigbee_3_0_Linux_Gateway_1_0_0/Firmware/Readme.txt: To use Zigbee Linux Gateway 3.0 with CC2531_GW_ZNP_Dongle_USB.hex, please disable the flag SKIP_BOOTLOADER_VALIDATION in npi_lnx_ipc.c and recompile the all the Linux servers, as this device must support the bootloader initialization performed by the gateway host.
    Note that this would not be required if you used a SimpleLink CC13x2/CC26x2 Launchpad.


    Perhaps worth trying a ZNP reset, as this related post mentions:
    e2e.ti.com/.../721582



    Regards,
    Toby

  • 0 in reply to Toby
    Prodigy 120 points

    Hi Toby,
    Thank you for your answer.

    Unfortunately I don't have sniffer logs available right now.

    I'm using the Z-Stack firmware from Z-Stack 3.0.2, after a SYS_RESET_IND is as follow:

    SYS_RESET_IND
     minor_rel: 07
     product_id: 00
     major_rel: 02
     transport_rev: 02
     hw_rev: 02
     cmd0: 41
     cmd1: 80
     reason: 00


    The host controlling the ZNP is a python library on linux. This same library is able to create a coordinator (using ZDO_START_FROM_APP) without issue.
    I tried to join a coordinator with security enabled before, yes, but I'm doing a reset of the stored network every time with this command:
    1- Use ZB_WRITE_CONFIGURATION to set ZCD_NV_STARTUP_OPTION to forget existing networks (0x03)

    Is this what you call factory reset of the ZNP ?
    BTW I have the same issue just after flashing the Z-Stack, or after a hard reset.

  • 0 in reply to Julien Le Guen
    Guru 735625 points
    Sniffer log is needed to analyze your issue and does your host also run Zigbee 3.0 with latest Z-Stack 3.0.3 ZNP?
  • 0 in reply to YiKai Chen
    Prodigy 120 points

    Hi,

    My end-device runs the precompiled binary provided with Z-Stack 3.0.2. 

    Here is the log from wireshark (ignore the "Bad FCS" indication).

    The first packet is the broadcast from a coordinator, the second packet is the beacon request from the ZED, and the third packet is the beacon response from the ZC.
    The ZED stays in 'DEV_NWK_DISC' and does not emit any other ZDO_STATE_CHANGE_IND after that.

    No. Time Source Destination Protocol Length Info
    26 -12.213076 0x0000 Broadcast IEEE 802.15.4 29 Data, Dst: Broadcast, Src: 0x0000, Bad FCS

    Frame 26: 29 bytes on wire (232 bits), 29 bytes captured (232 bits) on interface 0
    Interface id: 0 (/tmp/ccsniffpiper)
    Interface name: /tmp/ccsniffpiper
    Encapsulation type: IEEE 802.15.4 Wireless PAN (104)
    Arrival Time: Jan 1, 1970 01:00:48.458561000 CET
    [Time shift for this packet: 0.000000000 seconds]
    Epoch Time: 48.458561000 seconds
    [Time delta from previous captured frame: 5.261726000 seconds]
    [Time delta from previous displayed frame: 5.261726000 seconds]
    [Time since reference or first frame: -12.213076000 seconds]
    Frame Number: 26
    Frame Length: 29 bytes (232 bits)
    Capture Length: 29 bytes (232 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: wpan:data]
    IEEE 802.15.4 Data, Dst: Broadcast, Src: 0x0000, Bad FCS
    Frame Control Field: 0x8841, Frame Type: Data, PAN ID Compression, Destination Addressing Mode: Short/16-bit, Frame Version: IEEE Std 802.15.4-2003, Source Addressing Mode: Short/16-bit
    .... .... .... .001 = Frame Type: Data (0x1)
    .... .... .... 0... = Security Enabled: False
    .... .... ...0 .... = Frame Pending: False
    .... .... ..0. .... = Acknowledge Request: False
    .... .... .1.. .... = PAN ID Compression: True
    .... ...0 .... .... = Sequence Number Suppression: False
    .... ..0. .... .... = Information Elements Present: False
    .... 10.. .... .... = Destination Addressing Mode: Short/16-bit (0x2)
    ..00 .... .... .... = Frame Version: IEEE Std 802.15.4-2003 (0)
    10.. .... .... .... = Source Addressing Mode: Short/16-bit (0x2)
    Sequence Number: 114
    Destination PAN: 0x5286
    Destination: 0xffff
    Source: 0x0000
    FCS: 0xec3f (Incorrect, expected FCS=0xd3fd)
    [Expert Info (Warning/Checksum): Bad FCS]
    [Bad FCS]
    [Severity level: Warning]
    [Group: Checksum]
    Data (18 bytes)
    Data: 0910fcff000001f68c282706004b12000860
    [Length: 18]

    0000 41 88 72 86 52 ff ff 00 00 09 10 fc ff 00 00 01 A.r.R...........
    0010 f6 8c 28 27 06 00 4b 12 00 08 60 3f ec ..('..K...`?.

     

     

    No. Time Source Destination Protocol Length Info
    27 -2.907599 Broadcast IEEE 802.15.4 10 Beacon Request, Bad FCS

    Frame 27: 10 bytes on wire (80 bits), 10 bytes captured (80 bits) on interface 0
    Interface id: 0 (/tmp/ccsniffpiper)
    Interface name: /tmp/ccsniffpiper
    Encapsulation type: IEEE 802.15.4 Wireless PAN (104)
    Arrival Time: Jan 1, 1970 01:00:57.764038000 CET
    [Time shift for this packet: 0.000000000 seconds]
    Epoch Time: 57.764038000 seconds
    [Time delta from previous captured frame: 9.305477000 seconds]
    [Time delta from previous displayed frame: 9.305477000 seconds]
    [Time since reference or first frame: -2.907599000 seconds]
    Frame Number: 27
    Frame Length: 10 bytes (80 bits)
    Capture Length: 10 bytes (80 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: wpan]
    IEEE 802.15.4 Command, Dst: Broadcast, Bad FCS
    Frame Control Field: 0x0803, Frame Type: Command, Destination Addressing Mode: Short/16-bit, Frame Version: IEEE Std 802.15.4-2003, Source Addressing Mode: None
    .... .... .... .011 = Frame Type: Command (0x3)
    .... .... .... 0... = Security Enabled: False
    .... .... ...0 .... = Frame Pending: False
    .... .... ..0. .... = Acknowledge Request: False
    .... .... .0.. .... = PAN ID Compression: False
    .... ...0 .... .... = Sequence Number Suppression: False
    .... ..0. .... .... = Information Elements Present: False
    .... 10.. .... .... = Destination Addressing Mode: Short/16-bit (0x2)
    ..00 .... .... .... = Frame Version: IEEE Std 802.15.4-2003 (0)
    00.. .... .... .... = Source Addressing Mode: None (0x0)
    Sequence Number: 87
    Destination PAN: 0xffff
    Destination: 0xffff
    Command Identifier: Beacon Request (0x07)
    FCS: 0xec42 (Incorrect, expected FCS=0x7588)
    [Expert Info (Warning/Checksum): Bad FCS]
    [Bad FCS]
    [Severity level: Warning]
    [Group: Checksum]

    0000 03 08 57 ff ff ff ff 07 42 ec ..W.....B.

    No. Time Source Destination Protocol Length Info
    28 -2.904525 0x0000 ZigBee 28 Beacon, Src: 0x0000, EPID: TexasIns_00:06:27:28:8c, Bad FCS

     

     

    Frame 28: 28 bytes on wire (224 bits), 28 bytes captured (224 bits) on interface 0
    Interface id: 0 (/tmp/ccsniffpiper)
    Interface name: /tmp/ccsniffpiper
    Encapsulation type: IEEE 802.15.4 Wireless PAN (104)
    Arrival Time: Jan 1, 1970 01:00:57.767112000 CET
    [Time shift for this packet: 0.000000000 seconds]
    Epoch Time: 57.767112000 seconds
    [Time delta from previous captured frame: 0.003074000 seconds]
    [Time delta from previous displayed frame: 0.003074000 seconds]
    [Time since reference or first frame: -2.904525000 seconds]
    Frame Number: 28
    Frame Length: 28 bytes (224 bits)
    Capture Length: 28 bytes (224 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: wpan:zbee_beacon]
    IEEE 802.15.4 Beacon, Src: 0x0000, Bad FCS
    Frame Control Field: 0x8000, Frame Type: Beacon, Destination Addressing Mode: None, Frame Version: IEEE Std 802.15.4-2003, Source Addressing Mode: Short/16-bit
    .... .... .... .000 = Frame Type: Beacon (0x0)
    .... .... .... 0... = Security Enabled: False
    .... .... ...0 .... = Frame Pending: False
    .... .... ..0. .... = Acknowledge Request: False
    .... .... .0.. .... = PAN ID Compression: False
    .... ...0 .... .... = Sequence Number Suppression: False
    .... ..0. .... .... = Information Elements Present: False
    .... 00.. .... .... = Destination Addressing Mode: None (0x0)
    ..00 .... .... .... = Frame Version: IEEE Std 802.15.4-2003 (0)
    10.. .... .... .... = Source Addressing Mode: Short/16-bit (0x2)
    Sequence Number: 60
    Source PAN: 0x5286
    Source: 0x0000
    Superframe Specification: PAN Coordinator, Association Permit
    .... .... .... 1111 = Beacon Interval: 15
    .... .... 1111 .... = Superframe Interval: 15
    .... 1111 .... .... = Final CAP Slot: 15
    ...0 .... .... .... = Battery Extension: False
    .1.. .... .... .... = PAN Coordinator: True
    1... .... .... .... = Association Permit: True
    GTS
    GTS Descriptor Count: 0
    GTS Permit: False
    Pending Addresses: 0 Short and 0 Long
    FCS: 0xec41 (Incorrect, expected FCS=0x6930)
    [Expert Info (Warning/Checksum): Bad FCS]
    [Bad FCS]
    [Severity level: Warning]
    [Group: Checksum]
    ZigBee Beacon, ZigBee PRO, EPID: TexasIns_00:06:27:28:8c
    Protocol ID: 0
    Beacon: Stack Profile: ZigBee PRO, Router Capacity, End Device Capacity
    .... .... .... 0010 = Stack Profile: ZigBee PRO (0x2)
    .... .... 0010 .... = Protocol Version: 2
    .... .1.. .... .... = Router Capacity: True
    .000 0... .... .... = Device Depth: 0
    1... .... .... .... = End Device Capacity: True
    Extended PAN ID: TexasIns_00:06:27:28:8c (00:12:4b:00:06:27:28:8c)
    Tx Offset: 16777215
    Update ID: 0

    0000 00 80 3c 86 52 00 00 ff cf 00 00 00 22 84 8c 28 ..<.R......."..(
    0010 27 06 00 4b 12 00 ff ff ff 00 41 ec '..K......A.

     

    Here are the AREQ I receive om the ZED (I'm using ZDO_STARTUP_FROM_APP):

    --------------------------------------------------------------------------------
    RX [parsed]:
    id: SYS_RESET_IND
    minor_rel: 07
    product_id: 00
    major_rel: 02
    transport_rev: 02
    hw_rev: 02
    cmd0: 41
    cmd1: 80
    reason: 00
    --------------------------------------------------------------------------------
    System reset successfully.
    TransportRev=2, ProductId=0, SwRev=2.7, HwRev=2
    Device info 0
    Setting configuration
    Registering AF
    Status = Success

    --------------------------------------------------------------------------------
    RX [parsed]:
    id: ZDO_STATE_CHANGE_IND
    state: 02
    cmd0: 45
    cmd1: c0
    --------------------------------------------------------------------------------
    Status : DEV_NWK_DISC

    --------------------------------------------------------------------------------
    RX [parsed]:
    id: APP_CNF_BDB_COMMISSIONING_NOTIFICATION
    status: 01
    commissioning_mode: 02
    cmd0: 4f
    cmd1: 80
    remaining_commissioning_mode: 04
    --------------------------------------------------------------------------------
    BDB Commissioning status BDB_COMMISSIONING_IN_PROGRESS
    BDB Commissioning mode BDB_COMMISSIONING_FORMATION

    Thanks!

  • 0 in reply to Julien Le Guen
    Guru 735625 points
    Can you attach your sniffer file?
  • 0 in reply to YiKai Chen
    Prodigy 120 points

    Sure, here is the pcapng file of the relevant packets.

    ZED_not_joining.zip

  • 0 in reply to Julien Le Guen
    Guru 735625 points
    I only see you device sends one beacon request and coordinator responds beacon frame with permit join enable. However, your device doesn't send association request to join, I think the problem is on device side. I would suggest you to erase your device chip and download application to test again.
  • 0 in reply to YiKai Chen
    Prodigy 120 points
    Thank you for looking at this issue.

    Yes this is exactly the question: the ZED should send an association request automatically once the beacon frame is sent by the ZC.
    But it does not do it, so what is happening? What could explain this behaviour?

    This was with a just-flashed CC2531-EMK with precompiled firmware 'CC2531ZNP-with-SBL.hex' from Z-Stack 3.0.2
    The exact same firmware, with same startup code (but as coordinator this time), is able to create a network without issue. This is happening only in End-Device or Router mode.
  • 0 in reply to Julien Le Guen
    Guru 735625 points
    Do you mean you also use ZAP-ZNP architect to act as end device?
  • 0 in reply to YiKai Chen
    Prodigy 120 points
    Yes, I have a CC2531 with the ZNP firmware that I want to use as an end device.
    My linux host is directly talking to the ZNP, through a python library (not from TI). I want my own application to act as a ZAP through this library.

    The issue does not come from the python ZNP library, I checked the ZNP command codes are correct wrt. the documentation.

    The issue is that once the ZED receives ZDO_STARTUP_FROM_APP, it sends a beacon request, emits ZDO_STATE_CHANGE_IND set to state 'DEV_NWK_DISC', and that's all. It's as if the MAC layer is ignoring the beacon frame from the ZC.

    - The following ZCD_NV_STARTUP_OPTION flags are set STARTUP_CLEAR_STATE | STARTUP_CLEAR_CONFIG
    - ZED soft-reset
    - ZC and ZED are on the same channel (20)
    - ZED PAN_ID is 0xffff so it should listen to everybody
  • 0 in reply to Julien Le Guen
    Guru 735625 points
    If you use ZTool +ZNP to act as device to join, does it works? You can refer to sunmaysky.blogspot.com/.../use-ztool-z-stack-30-znp-to-set-up.html
  • 0 in reply to YiKai Chen
    Prodigy 120 points
    No it does not work, I see the beacon request and the beacon frame on the sniffer, and that's it.
  • 0 in reply to Julien Le Guen
    Guru 735625 points
    If you follow the steps in the link using ZTool to setup coordinator and device, can device join coordinator?
  • 0 in reply to YiKai Chen
    Prodigy 120 points
    Ok I think I found the issue. Thanks a lot for your help!

    I was setting the configuration bits using the Simple API function ZB_WRITE_CONFIG.
    Following the exact same procedure but using SYS_OSAL_NV_WRITE instead (with the same configuration), it now works, the ZED is able to join the network.

    What is happening with the SAPI configuration in this case? Why is it unable to properly configure the device?
  • 0 in reply to Julien Le Guen
    TI__Mastermind 33640 points

    Glad to see you resolved the issue, and thanks for sharing the method you used to address it!

    I assume that it's because ZB_WRITE_CONFIG is used to write a configuration property (ZCD_NV_NIB, ZCD_NV_DEVICE_LIST, ZCD_NV_ADDRMGR, or ZCD_NV_NWKKEY), but apparently ZCD_NV_STARTUP_OPTION is not interpreted as a configuration property.

    The corresponding CMD1 of ZB_WRITE_CONFIG on the ZNP is MT_SAPI_WRITE_CFG_REQ. This command is handled in MT_SapiWriteCfg (found in MT_SAPI.c), also included below:

    static void MT_SapiWriteCfg(uint8 *pBuf)
{
  uint8 retValue, cmdId;

  /* Parse header */
  cmdId = pBuf[MT_RPC_POS_CMD1];
  pBuf += MT_RPC_FRAME_HDR_SZ;

  if ((pBuf[0] != ZCD_NV_NIB) && (pBuf[0] != ZCD_NV_DEVICE_LIST) &&
      (pBuf[0] != ZCD_NV_ADDRMGR) && (pBuf[0] != ZCD_NV_NWKKEY))
  {
    if ((zb_WriteConfiguration(pBuf[0], pBuf[1], &pBuf[2])) == ZSUCCESS)
    {
      retValue = ZSuccess;
    }
    else
    {
      retValue = ZFailure;
    }
  }
  else
  {
    retValue = ZInvalidParameter;
  }

  /* Build and send back the response */
  MT_BuildAndSendZToolResponse(((uint8)MT_RPC_CMD_SRSP | (uint8)MT_RPC_SYS_SAPI), cmdId, 1, &retValue );
}

    Perhaps you can verify whether ZInvalidParameter (value is 0x02) is received/handled by the ZAP.

  • 0 in reply to Toby
    Prodigy 120 points

    Hi, thank you for pointing me to the relevant source code. Actually it seems that all configuration parameters are supported except those listed?

    The documentation does not mention any limitation for ZB_WRITE_CONFIGURATION (see 3.7.1.8 in Z-Stack Monitor and Test API p41), maybe a list of supported configuration attributes could be added to avoid this problem in the future :)

    Anyway let me add that I was pleasantly surprised by the reactivity of this forum, thank you for your time!

  • 0 in reply to Julien Le Guen
    TI__Mastermind 33640 points

    Ah, good catch! The only other thing I can think of is from this related post, which suggests that SAPI is (likely) deprecated in 3.0.1+.

    As always, appreciate the feedback.

  • 0 in reply to Toby
    Guru 735625 points

    @Toby Not sure if TI regards SAPI interface is deprecated. If this is true, I would suggest you to remove SAPI related code and descriptions from source and document ms.