• State TI Thinks Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 57 subscribers
  • Views 442 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.

CC1352P: Problems with LEAVE on Zigbee network

Randy Gómez
Intellectual 525 points
Part Number: CC1352P
Other Parts Discussed in Thread: Z-STACK

Hello community,


We are working on a Zigbee project with a CC1352P connected to an AM437x. We currently have a problem with the LEAVE. To remove devices from the network, we use the NWK_REMOVE_DEVICE_REQ command as described in the documentation and as it is implemented in the example application made in NodeJS. This command returns a NWK_ZIGBEE_DEVICE_IND_VALUE with nwkDeviceStatus_t.DEVICE_REMOVED, and when we check the server's CSV files, the device is deleted (commented line). However, when we check Ubiqua we see that the LEAVE command was not sent to the device. We have devices that behave in a specific way when they are removed from the network (for example, they show "no net"), and we see that this does not happen. We have tested with different types of devices and always nothing. What could be the problem here and how can we fix it ???

BR,

Randy

  • 0
    TI__Mastermind 28250 points

    Hi,

    Which SDK are you using for CC1352P ?

    What Zigbee profile are the devices running (Zigbee 3.0, Zigbee HA, ...) ?

    Are these devices directly connected to the ZNP, or is there a hop in between ?

    I was able to use NWK_REMOVE_DEVICE_REQ to remove devices (one Zigbee HA end device (Z-Stack 1.2.2a), one Zigbee 3.0 router (from Zigbee Linux Gateway Firmware/cc26x2_sampleapps folder)). The ZNP I used is the image provided in the Zigbee Linux Gateway Firmware/znp folder.

    During this period, is the gateway able to send other types of commands (e.g. toggle light), and are those commands seen in the sniffer?

    Can you provide a sniffer log which includes this sequence:

    1. Devices joining.
    2. Gateway sending application commands to these devices (e.g. toggle light), and/or these devices sending application commands to gateway.
    3. Executing NWK_REMOVE_DEVICE_REQ at gateway.
    4. Repeat step 2.
    5. Let the network run for a couple more minutes.

    Regards,
    Toby

  • 0 in reply to Toby Pan
    Intellectual 525 points

    Hi Toby,
    Thanks for the help. We did the test with the original Zigbee Linux Gateway "Zigbee_3_0_Linux_Gateway_1_0_1\Firmware\znp\CC1352P2LP_GW_ZNP_UART.hex". With this firmware it worked.

    We had made a firmware using the zs4.20.01.04 SDK. With this firmware the LEAVE command did not work for us, using the same environment. We will do more tests and bring as much information as possible to find the problem.

    BR,

    Randy

  • 0
    Guru 735455 points

    I would suggest you to use sniffer to check what happens over the air.

  • 0 in reply to Randy Gómez
    TI__Mastermind 28250 points

    Thanks for confirming.

    This seems to have occurred due to a fix we had introduced for parsing the MT_ZDO_EXT_SEC_APS_REMOVE_REQ command at the ZNP (fix was introduced in 3.40 SDK).

    For now, if using a 3.40+ ZNP (including 4.20), fixes could be applied either to ZNP or the gateway.
    The following approach shows how to do the fix at gateway (in file C:\ti\Zigbee_3_0_Linux_Gateway_1_0_1\source\Projects\zstack\linux\zstackserverznp\znp_zdo.c).

    ZStatus_t ZDSecMgrAPSRemove( uint16 nwkAddr, uint8 *extAddr, uint16 parentAddr )
{
  uint8 status;
  uint8 buf[12];

  buf[0] = LO_UINT16( nwkAddr);
  buf[1] = HI_UINT16( nwkAddr);
  osal_memcpy( &buf[2], extAddr, 8 );
  buf[10] = LO_UINT16( parentAddr );
  buf[11] = HI_UINT16( parentAddr );

  status = (uint8) sendNPIExpectDefaultStatusZDO( MT_ZDO_EXT_SEC_APS_REMOVE_REQ,
      12, buf );

  return (status);
}

    Note that the order of addresses has been updated to match how the 3.40+ ZNP handles this command. Please try this, rebuild the gateway, and let us know if the NWK_REMOVE_DEVICE_REQ works.
    I have tested this fix with the 4.20 ZNP working with the 1.0.1 Zigbee linux gateway. Note that because this will change how the gateway passes the command down to ZNP, this fix should only be used for 3.30+ ZNPs. If using a 3.30 (or earlier) ZNP, including all ZNP images provided in the gateway, leave this gateway source file as-is (without the change provided here).