LAUNCHXL-CC1352P: zstackmsg_CmdIDs_AF_DATA_CONFIRM_IND message is returning an unknown status value

Toby,

Thanks for the reply. However, this is a bit distressing. I would expect to see only values from the zstack_ZStatusValues enumeration, because that's the way the zstackmsg_afDataConfirmInd_t struct is defined, but it's apparent there can be other values as well. Do you know if there is a complete list of status values, in addition to those in zstack_ZStatusValues, that could appear in the status value?

Because I'm sending several messages in a row using Zstackapi_AfDataReq() , I'm trying to find out why many are not getting through to the coordinator. I suspect I'm "overwhelming" the ZStack thread with more messages than it can handle. I think I will have to send a message, wait for the callback to determine the success or failure, then send another message, and so on. Do you agree? Do you have sample code that does this, or some other suggestion on how to use Zstackapi_AfDataReq() properly?

Thanks,

Tim

The statuses defined in zcomdef.h and and zstack_ZStatusValues should constitute the full collection of statuses.

Also consider increasing NWK_MAX_DATABUFS* in nwk_globals.c.

Yes, what you've described is a good idea. Perhaps try calling Zstackapi_AfDataReq in the case which handles zstackmsg_CmdIDs_AF_DATA_CONFIRM_IND.

How often are you calling Zstackapi_AfDataReq? Can you provide a sniffer log of what is happening?

Toby,

I just installed SmartRF Sniffer Agent and Wireshark. How do I create a sniffer log? Is it a Sniffer Agent log or a Wireshark log?

It will be a Wireshark log.
Details on setting up the sniffer are here: https://e2e.ti.com/support/wireless-connectivity/zigbee-and-thread/f/158/t/699648?tisearch=e2e-sitesearch&keymatch=faq%3Atrue

Toby,

I did a capture in Wireshark, then saved the capture in a Wireshark "capture file". This created a file with the extension "pcapng". I attempted to attach this file but when I tried to post to the forum it complains that it's not an allowed file extension. How can I upload this file?

Thanks,

Tim

Please compress it to a zip and attach.

Attached is the compressed Wireshark log file.

wireshark_log.zip

Many of the packets are encrypted... can you provide the NWK key as well?

The packets seem quite large, what is the size of the payload you are passing to Zstackapi_AfDataReq?

Toby,

I send 22 Zigbee packets every 20 seconds. Most packets have a payload size of 86 bytes, but a few packets are smaller.

My project is based on the stock zed_switch example, and I'm using whatever security keys are in that example.

This is what I'm using, from nwk_globals.h

#define DISTRIBUTED_GLOBAL_LINK_KEY { 0xD0, 0xD1, 0xD2, 0xD3, 0xD4, 0xD5, 0xD6, 0xD7,\
0xD8, 0xD9, 0xDA, 0xDB, 0xDC, 0xDD, 0xDE, 0xDF }

#define DEFAULT_TC_LINK_KEY { 0x5a, 0x69, 0x67, 0x42, 0x65, 0x65, 0x41, 0x6c,\
0x6c, 0x69, 0x61, 0x6e, 0x63, 0x65, 0x30, 0x39 }

Is this what you need?

The TCLK is used to encrypt the NWK key which is transported to a device during its joining procedure. Afterwards, this NWK key is used to encrypt the NWK payload.

Do you have a log of the joining process that you can share?
If not, can you re-capture the sniffer logs to include the joining process?

Have you already tried your idea of waiting for success status before sending another packet?

Toby,

I haven't yet implement waiting for success status of a packet before sending another packet. I will try that today.

Attached is a Wireshark log. In this log I capture the start of the coordinator, followed by the start of the end device.

Also, since we are on the subject of startup. My coordinator and end device are based on the zc_light and zed_sw example projects. These two devices are supposed to save the network settings in flash so that when they startup they will remember their settings and reform the network. Usually this works, however they often fail to form a network. Have you seen this problem? How can I get a look at the values stored in flash, to help me debug this?

Thanks,

Tim

wireshark_startup_log.zip

It looks like you either reset or power-cycled the devices for the log. In this case, the ZED sends a NWK encrypted Rejoin Request (no key transport is shown in the sniffer log).

Can you erase flash on both devices, reflash them, then take the sniffer log?

If these are out-of-box examples, there should be no issue with commissioning when the devices are reset...
Although you could use Smart RF Flash Programmer 2 to read flash contents, I doubt that this level of debug is necessary for finding the cause of network recovery after reset.
How are you determining that the devices have not joined their previous network?

Toby,

Yes I did power cycle the devices before I took the sniffer log.

Usually the network is reformed, but not always. I can tell when the end device has not joined the network in 3 ways:

1. In zclSampleSw_processZStackMsgs(),when the zstackmsg_CmdIDs_DEV_STATE_CHANGE_IND message is received, function UI_DeviceStateUpdated() is called (this is in file zcl_sampleapps_ui.c). This function turns on the green LED when the device has joined the network as an end device, router or coordinator. When the LED is off, I know it's not on the network.

2. In function zclSampleSw_ProcessCommissioningStatus() I get the BDB_COMMISSIONING_PARENT_LOST message. The commissioning status is not BDB_COMMISSIONING_NETWORK_RESTORED, as it would be if we rejoined the network, so I know we have not rejoined the network.

3.The end device tries to send messages, but they are not reaching the coordinator.

Regarding redoing the sniffer log, I will erase both devices, then reflash them.

1. At what point in this process would you like me to start recording the sniffer log?

2. Do you want me to press button 1 on both devices to start the commissioning process, or should I leave the buttons alone?

Thanks,

TIm

After ZC and ZED reset:
- if ZC restores its network before the ZED attempts to find its previously joined network, then the ZED rejoins immediately
- if ZED attempts to find its previously joined network before the ZC restores its network, then the ZED will re-attempt this after SAMPLEAPP_END_DEVICE_REJOIN_DELAY ms (default is 10000 ms, or 10 seconds)

Have you waited the full 10 seconds to give the ZED a chance to re-find its network?

If you restart/power cycle only the ZED (while the ZC remains powered on), the ZED should be always able to rejoin.
Conversely, if you restart/power cycle only the ZC (while ZED remains powered on), the ZED should be able to rejoin the network after at most SAMPLEAPP_END_DEVICE_REJOIN_DELAY ms.

For redoing the sniffer log:
- start the sniffer before either device has performed commissioning
- after starting the sniffer, perform commissioning (BTN-1) first on the ZC, then the ZED

Toby,

Thanks, I am able to decrypt the packets in the newest log.

However, does this log capture the time period in which the original issue occurs?

Have you implemented the wait-before-send method? If yes, is there a corresponding log?

Thanks for your help Toby. I'm currently out of town and will respond when I get back to the office.

Tim, sounds good.

If this thread locks before you return to the office, feel free to create a new thread and reference this one.