• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 55 subscribers
  • Views 459 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

End device not sending Association Request after Beacon

Gustavo Vasoin
Prodigy 30 points
Part Number: CC2652P
Other Parts Discussed in Thread: Z-STACK, SIMPLELINK-CC13XX-CC26XX-SDK

join_device.zip

Hi, we have developed a Zigbee Router that implements multiple functionalities. However, we have discovered a weird behaviour. When adding ZCL_ACE to the build predefined symbols, the router stops working as such, only working as an End device, we have tried tracing this with wireshark, and in the capture, we see that the end device we try to join with the router as an inbetween, doesn't send an Association Request after receiving a Beacon message from our router. In the attached capture, Frame 7708 corresponds to the beacon from a router without ZCL_ACE enabled, and frames 8591 and 8592 to devices with ZCL_ACE enabled, both in response to  Beacon request from the same end device.

We don't know what can be causing this behaviour, since the Beacon issued from both Routers seems equal.

  • 0
    TI__Guru**** 219007 points

    Hi Gustavo,

    The behavior you are describing is quite odd since ZCL_ACE is limited to the ZCL layer and should not affect the ZDO or BDB layers of Z-Stack.  Are you experiencing this issue with the zr_cie TI examples as well?  These are tested and verified for operation each quarter the SDK is updated.  Which SIMPLELINK-CC13XX-CC26XX-SDK version are you using, and what are the CCS and compiler dependencies?  Make sure to factory reset the device or erase all device memory before re-programming.  Not much can be gathered from the sniffer log other than the fact that the nodes are sending Beacon Requests, but you can further debug the devices in question to determine more about their commissioning and device states.

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Prodigy 30 points

    Thanks for the answer, we kept trying to find the cause, and what we found, is that it's not exactly ZCL_ACE the cause, because when removing ZCL_WD, the routing also works.

    This project started based on the zr_warningdevice example, and we kept adding new functionality, so maybe it's some memory or flash related problem. It's still baffling how we can see the beacon sent in the sniffer log, but the end device doesn't send any messages. We can't debug the end device we used in the sniffer log, since it's a third party sensor, but we will be trying to pair one of our own devices, configuring it as an end device, though another of our routers to debug the binding process.

  • 0 in reply to Gustavo Vasoin
    TI__Guru**** 219007 points

    You have a good point, stack and heap sizes could be causing an issue for routing devices which would not exist for end device configurations.  Referring to the Z-Stack User's Guide, you can monitor Heap allocation and management with HEAPMGR_METRICS,further increase the HEAPMGR_SIZE inside app.cfg, and look through Configure the Heap to make sure that heap settings are suitable for your application.  The APP_TASK_STACK_SIZE is defined in main.c and STACK_TASK_STACK_SIZE is defined in zstackstartup.c, you could increase these as well to determine their affect on application behavior.

    Regards,
    Ryan