CC2652R: Frame Pending incorrect when interrupted

Mathew Heard

Part Number: CC2652R
Other Parts Discussed in Thread: Z-STACK

Tool/software:

With the CC2652R and simplelink 6.41.00.17 we have seen the following

What this shows is that when a resend is interrupted by a packet received by that sensor (both parties trying to tx) TI replies with an incorrect frame pending causing the sleepy ED to shut down its receiver.

This is likely because pending in the srcmatch offloading is cleared as the packet is moved to transmit rather than when tx is complete.

Can this be fixed in the blob please?

over 1 year ago

0 Toby over 1 year ago

TI__Mastermind 35070 points

Hi,

Can you try running this test on the latest SDK for CC2652R?
https://dev.ti.com/tirex/explore/node?node=A__AEIJm0rwIeU.2P1OBWwlaA__com.ti.SIMPLELINK_CC13XX_CC26XX_SDK__BSEc4rl__LATEST

Issues in the 15.4 Stack library may have been fixed there.

Thanks,
Toby

0 Mathew Heard over 1 year ago in reply to Toby

Intellectual 741 points

I have tested both 7.40 and 7.41, neither fixes it.

I note there are some relevant changes in the source code in 7.41 (but nothing that I can see about them them in the changelog!) however these do not help.

From 7.41.00.17:

0 Toby over 1 year ago in reply to Mathew Heard

TI__Mastermind 35070 points

Can you share reproduction steps, starting from TI example running on TI launchpad?

Is this a Zigbee example?

0 Mathew Heard over 1 year ago in reply to Toby

Intellectual 741 points

This is ZNP.

The easiest way we have to replicate it is:

- to increase mac retries to increase the likelihood of a missed ACK from the ZED.

- place a few ZED sensor at 20-30 LQI away

- setup a regular poll control (e.g 10min)

- leave a sniffer running

Eventially a MAC ACK from the ZED will be missed by the ZC (e.g due to collision) and this will illustrate this sequence of events.

We get 1-2 per day on a 3 sensor network where the ZEDs are located at around 20-40 lqi away

We have confirmed the cause. Frame Pending not sent when ZC (ZNP) is in an interrupted transmit. Frame Pending (offloaded to hardware via srcmatch) is likely cleared when packet is dequeued for transmit not when txComplete as it should be. In all other cases frame pending is correct.

0 Toby over 1 year ago in reply to Mathew Heard

TI__Mastermind 35070 points

Thank you for sharing these details.

Generally, blob/lib fixes would be fixed within the next 1-2 SDKs.

Does the device recover from this state? It seems that during the next polling cycle, the device would still poll the ZC.

I'll file a ticket with our Z-Stack RnD team.

Will update here within 5 business days.

0 Mathew Heard over 1 year ago in reply to Toby

Intellectual 741 points

The ZED is will be fine on the next Data Req (MAC Poll) cycle. There is however a chance for this to repeat.

One of the ZEDs we work with has a high sensitivity for triggering a re-connect (it appears to be three failed cycles). As small as it is the chance of this repeating is, it can happen. And we think its been observed in the fleet.