CC2538: ZNP - Why all the retries?

Jason Cole26

Part Number: CC2538
Other Parts Discussed in Thread: Z-STACK, CC2531, CC2531EMK

I have attempted to add a device to a Zigbee network, however the device does not respond with a node descriptor response. I notice lots of retries from the ZNP in quick succession here. Is it possible to make the retries less aggressive or is this merely to overcome fast fading?

over 8 years ago

0 Jason Cole26 over 8 years ago

Intellectual 710 points

0 YiKai Chen over 8 years ago

Guru 735695 points

What's your device?

0 Jason Cole26 over 8 years ago in reply to YiKai Chen

Intellectual 710 points

It's an Innr BY165 smart light

0 YiKai Chen over 8 years ago in reply to Jason Cole26

Guru 735695 points

It seems not a device from TI. Since there is no MAC ack from this BY165 smart light when coordinator sends node descriptor request, I suggest you to contact manufacturer of this device for help.

0 Jason Cole26 over 8 years ago in reply to YiKai Chen

Intellectual 710 points

I have done that already. I thought that we should be able to interface to any Zigbee device or is that nieve?

0 YiKai Chen over 8 years ago in reply to Jason Cole26

Guru 735695 points

Try not to request node descriptor from your coordinator to see if it works.

0 JasonB over 8 years ago in reply to Jason Cole26

TI__Expert 8950 points

Hi,

I'm guessing that the joining device did not receive the Transport Key correctly after association, and therefore cannot decrypt the Node Descriptor Request from the TI ZC. Can you upload the .cubx file please?

By the way, I'm not sure if this is related but your ZC is reporting it's IEEE address backwards (in the Assoc Rsp MAC Src), it should be 00:12:4B:00:A5:AF:B5:14. This could be the issue (joining device could be storing IEEE address one direction for parent/TC address but the other direction for NWK key source), but I'd need the full log to determine this.

0 Jason Cole26 over 8 years ago in reply to JasonB

Intellectual 710 points

OK I'll put that theory to the test tomorrow by sending it some messages, and generate another log.

I've added a notification to the ZStack so that my application is informed of any device that joins the network, details or no details.

I suspect very strongly there are race conditions in the ZNP code since sometimes it will transmit a permit-join minutes after I command it, plus (according to Ubiqua) it will send multiple spurious permit-joins several minutes later. At times we are having to cold-start the ZNP. This suspicion of mine is also consistent with the delay-the-frequent-retries pattern observable in the trace above.

0 YiKai Chen over 8 years ago in reply to Jason Cole26

Guru 735695 points

For your reference, we had tested this bulb with TI Z-Stack coordinator and it can work with our GW without problem. I think it will be helpful to provide your sniffer log to know what happens.

0 Jason Cole26 over 8 years ago in reply to YiKai Chen

Intellectual 710 points

OK I will also try the Beaglebone with CC2531 dongle :)

0 YiKai Chen over 8 years ago in reply to Jason Cole26

Guru 735695 points

Yes, Z-Stack Home GW reference design running on BBB with CC2531EMK should work.

0 Jason Cole26 over 8 years ago in reply to YiKai Chen

Intellectual 710 points

OK here is another example of a slew of retries:

0 Jason Cole26 over 8 years ago in reply to Jason Cole26

Intellectual 710 points

0 YiKai Chen over 8 years ago in reply to Jason Cole26

Guru 735695 points

Couldn’t understand your descriptions. Can you elaborate?

0 Jason Cole26 over 8 years ago in reply to Jason Cole26

Intellectual 710 points

TransportKeyRetries.zip

0 Jason Cole26 over 8 years ago in reply to Jason Cole26

Intellectual 710 points

Ubiqua traces ^

Link Key is 69:90:2e:ec:dd:6d:99:6d:aa:0d:be:25:31:5b:54:7b

We are looking at the slew of retries of the Link Key - sequence number 197, as highlighted in the above image. The end-device successfully joins.

I added some tracing to the mac-tx and the following entries correspond to the Link Key retries:

MAC_TxS: TS 893208 CSMA 1 FrmeTyp 1 ReTx 0 Len 71: FC 8861 SN 197 PAN ae3 nAddr d80f
MAC_TxS: TS 893235 CSMA 1 FrmeTyp 1 ReTx 1 Len 71: FC 8861 SN 197 PAN ae3 nAddr d80f
MAC_TxS: TS 893244 CSMA 1 FrmeTyp 1 ReTx 1 Len 71: FC 8861 SN 197 PAN ae3 nAddr d80f
MAC_TxS: TS 893263 CSMA 1 FrmeTyp 1 ReTx 1 Len 71: FC 8861 SN 197 PAN ae3 nAddr d80f

Where...
TS is the timestamp obtained from osal_GetSystemClock()

CSMA is one of these:
#define MAC_TX_TYPE_SLOTTED_CSMA 0x00
#define MAC_TX_TYPE_UNSLOTTED_CSMA 0x01
#define MAC_TX_TYPE_SLOTTED 0x02
#define MAC_TX_TYPE_GREEN_POWER 0x03

FrmeTyp is "pMacDataTx->internal.frameType"

ReTx is the state of "txRetransmitFlag"

Len is "pMacDataTx->msdu.len"

FC is the frame control in the packet
SN is the sequence number in the packet
PAN is the PAN-Id in the packet
nAddr is the destination network address in the packet

So we can see the same message is sent 4 times, with 3 retries in quick succession.

So, two questions:
1) What is the interval of the code returned from osal_GetSystemClock() ?
2) Is it normal/expected for these retry periods to be this short?

I note in the code that "macTxFrameRetransmit" is called from a library so I cannot see what logic is used to determine when to perform the retry.

0 YiKai Chen over 8 years ago in reply to Jason Cole26

Guru 735695 points

It’s the device doesn’t respond MAC ack so the sender resends the transport key. What’s your device?

0 Jason Cole26 over 8 years ago in reply to YiKai Chen

Intellectual 710 points

The device is one of ours, based on the GenericApp

0 YiKai Chen over 8 years ago in reply to Jason Cole26

Guru 735695 points

If you use GenericApp example without any modification, do you still see the same problem.

0 Jason Cole26 over 8 years ago in reply to YiKai Chen

Intellectual 710 points

We will try that later. We will also try holding off the "data request" transmissions from the end device which are probably causing CSMA collisions.

0 YiKai Chen over 8 years ago in reply to Jason Cole26

Guru 735695 points

What do you mean also try holding off the "data request"?

0 behold li over 8 years ago in reply to Jason Cole26

Expert 2745 points

Do you confirm your ZNP device have been configured correct when start application?

If ZNP device configure incorrect,this will cause other device do not join the network(e.g. NV write error,ZNP device not starting OSAL immediately,but instead of will keep "Hold Status" for wait high level gateway application to configure NV items and to start it)

By the way,do you confirm your all end device and coordinator built-in the same TCLK and network key ?,if not,join may be died.

0 YiKai Chen over 8 years ago in reply to behold li

Guru 735695 points

According to sniffer log, the device joins successfully in the end. Only transport key retried transmitting several time due to no MAC ack.

0 JasonB over 8 years ago

TI__Expert 8950 points

Hi,

I'm pretty sure the Transport Key issue you're seeing is due to a race condition that we discovered recently. In short, after a new device joins the network, ZDApp starts an NV write operation to update the network information in NV flash, and this is a blocking operation that can take a large amount of time, up to ~500ms. Even though the ZED polls for the Transport Key in time, the ZC does not send out the Transport Key fast enough due to the blocking NV operation, and by the time it is actually sent out, the ZED has closed its receiver.

We have a macro that will stagger the start time of the NV write operation (this is in the ZNP project, not the gateway project) Try changing the value of ZDAPP_UPDATE_NWK_NV_TIME from the default of 700 (ms) to a larger value, like 3500, this will make the NV update operation start later and thus will not interfere with the network commissioning.

0 YiKai Chen over 8 years ago in reply to JasonB

Guru 735695 points

@jason I suspect the same thing but just not sure. Ha!

0 Jason Cole26 over 8 years ago in reply to YiKai Chen

Intellectual 710 points

I increased ZDAPP_UPDATE_NWK_NV_TIME to 7000 and the channel is a lot cleaner. Thanks guys :)

0 YiKai Chen over 8 years ago in reply to Jason Cole26

Guru 735695 points

Increase ZDAPP_UPDATE_NWK_NV_TIME to 3500 should be good enough. I suggest you not use extend it up to 7000.

0 Jason Cole26 over 8 years ago in reply to YiKai Chen

Intellectual 710 points

Surely it simply means the NVRAM is potentially updated less frequently?

0 JasonB over 8 years ago in reply to Jason Cole26

TI__Expert 8950 points

Not less frequently, just at a later period in time. All that macro does is define at what time the stack will start the NV write operation after it is requested. The reason it is helping in this case is that the network association procedure in Z-Stack 3.0.x can take more than 700ms from the time the operation is requested within the stack, depending on the ZED poll rate. As long as the delay is sufficiently long, there should be no issues, from my tests it shouldn't need to be longer than 3500ms but your mileage may vary depending on what your application is doing.

0 Jason Cole26 over 8 years ago in reply to JasonB

Intellectual 710 points

One more question - what is the interval of the code returned from osal_GetSystemClock() ?

0 YiKai Chen over 8 years ago in reply to Jason Cole26

Guru 735695 points

it returns local clock in milliseconds.

Zigbee & Thread

Zigbee & Thread forum

CC2538: ZNP - Why all the retries?