CC2652R7: zStack coordinator and ZED sleep function

Hello Sylvain,

Is your ZED a TI device using the same SDK as well?  If so, what example is being evaluated?  The ZC has no control over the power consumption of a sleepy end device.  ZED Power Mode of Operation is determined inside of the Z-Stack -> Power Management module of SysConfig, where you can also determine the Poll Period.  If you are not using the CUI (Customer User Interface, i.e. LEDs, pushbuttons, and UART) on your custom board then you should modify the Project Properties -> CCS Build -> Arm Compiler -> Predefined Symbols to define "CUI_DISABLE" and "xBOARD_DISPLAY_USE_UART" instead of their prior settings.  This is documented in the Power Configuration section of the Z-Stack User's Guide, where you can also consult the Z-Stack Overview section to understand more about ZED behavior.  How do you determine that the ZED is not entering sleep mode?  Even sleepy end devices can respond to ZC requests after a data poll or send ZCL messages whenever necessary.  TI tests and validates the power consumption of ZEDs every quarterly update of the SDK to ensure a robust and reliable solution.

Regards,
Ryan

Hello Ryan,

My ZED is not a TI device.

I was looking for informations about how the sleep mechanism works to figure out where, between ZC and ZED, may be the error. According your reply I think it is the ZED, as ZC has no control over the sleep/run function of a ZED.

For my ZC, I have already done (I think) everything needed about CUI, buttons, UART... It works fine.

I determine that ZED is in sleep mode by monitoring power consumption. Actually it's a deep sleep mode, where radio should be turned off (which is sadly not the case). In this state only RTC or hardware interrupt can wake up the system and resume communication.

I'll let this thread open for few days as I'm waiting informations from ZED manufacturer. It may rise new questions about zStack.

Anyway thanks for your quick reply.

Sylvain SERRE

ZED only wakes up to do polling its parent node for checking if there’s any data for it to receive. If yes, it would open RX for a short period to receive data and stop RX to enter sleeping mode. If not, ZED would go straight to sleep. The other things would wake up ZED are GPI interruption or scheduled timer events. Otherwise, ZED is In sleeping mode.

Hello,


I sniffed with zShark/Wireshark zigbee exchanges between coordinator (CC2657R7) and ZED device during finding & binding process and sent it to ZED manufacturer. Here is his response:

1.TI GW initiated the route request frame (447) after our device announcement(434,436) which is not expected behavior.

2.APS Ack(449-452) for Node descriptor response (439) is send from GW directly to the end device without the poll request(Data request) from End device.

3.And in between we can see few frames received by end device with the poll request.

4.Since key exchange has failed based on frames 546 to 549, the communication is not established after that, and our device is not entering into deep sleep.


At this point I really don't know what to do to fix this issue. And my knowledge of Zigbee is too low to tell which device is faulty here.

Is someone here kindly enough to review wireshark the logs with TI perspective? (I'd like to attach it to my message but I cannot find how)

Is the ZED joining the ZC directly or through a ZR device?  How many devices currently exist within the network, and can you reduce the test network to only two devices for better debugging?  Also, is the ZED using Zigbee 3.0 or a different Specification version?  You can directly drag-and-drop the sniffer log into the Reply box or click Insert -> Image/video/file and navigate to the log's directory on your computer.

Regards,
Ryan

Hello,

ZED is joining the ZC directly.

There is only this ZED on network, nothing more.

ZED is using 3.0 R22

As I understood what explained to me the ZED manufacturer, the logs shows that the ZC acts as if ZED is a ZR and not a ZED. The result is that ZC sends data without receiving a data request first.

CoordinatorTiVsZED_20230201.zip

Do you have a network key and/or filtered sniffer log parameters which can be provided?  If the Capability Information in the Device Announce from the ZED shows the Device Type bit as FFD (Full Function Device) instead of RFD (Reduced Function Device) then it will be treated as a ZR node.  Other important bits include the Power Source and Receiver On When Idle, although these should not affect how the ZC behaves.  The Capability Information byte of a ZR is typically 0x8E as compared to 0x80 for a ZED.

Regards,
Ryan 

Sorry about that, yes I have filter for Wireshark. Initially the one recommended by zShark: udp.port==17754 && ip.ttl==128 && !icmp

But ZED manufacturer use a better one (I think): zbee_nwk.proto_version == 2

I'll try to find Device Announce message to find out about FFD/RFD information.

Thanks for your help so far!

Hello again,

I can confirm that ZED is not FFD. Here is the Device announcement field

By the way, to analyse data the key to enter in Wireshark is "5A:69:67:42:65:65:41:6C:6C:69:61:6E:63:65:30:39" (ZigbeeAlliance09)

I cannot decrypt the packets with either Wireshark 3.0.X or 4.0.X, which is making it difficult to further diagnose the issue.  The default Global Link Key is entered in the preferences.

Is it possible that this device or IEEE address has joined the network before as a router node?  Have you tried factory resetting the ZC, or erasing all device memory before reprogramming?

Regards,
Ryan

I doubt that ZED has joined network before as a router, its code is unchanged since the start of our test.

I did not try to erase all ZC memory, it's something I can try.

I just received another (different) zigbee ZED to compare and see if there is the same issue. I'll let you know.

Regards,

Sylvain

Hello,

I tested another ZED ((MIR-TE100-TY), which works. Here is the wireshark logs.

I can easely see a difference, this time the communication stop after finding and binding, as it should. But I cannot tell more. I have sent those logs to ZED manufacturer for analysis.

Ryan, It's odd you cannot decrypt logs with wireshark. I use wireshark Version 4.0.3 (v4.0.3-0-gc552f74cdc23) with a pretty simple filter/key, see attached image.

CoordinatorTiVsTuyaTherm.zip

It would be very helpfull if someone can tell me what is going wrong with first ZED...

Thanks,

Sylvain

Do you design first ZED by yourself or it's from 3rd party?

It's a self design product, custom hardware based on Microchip solution. Zigbee stack is also from Microchip. That why I send informations to both Microchip and TI at every step until I find out where is the error.

I think the issue is on device side. If it’s Microchip solution, you should contact and wait Microchip response.