CC2652P: nwkDB buffer is full.

It seems that the Radio CPU in CC2652P is down.

Hi,

Can you describe the network traffic in your test?

Is this with custom board? Or TI launchpad?

Thanks,
Toby

Zigbee module, custom board.

This issue seems like this:

Function "MAP_MAC_McpsDataReq" is executed, but "MAC_MCPS_DATA_CNF" is not triggered. In a few seconds, the counter of  "MAP_MAC_McpsDataReq" is increasing but the counter of "MAC_MCPS_DATA_CNF" will not increase.

As I know, in CC2652P, the MAC Layer is executed by RF-Core(Cortex-M0).

Can you describe the network traffic in your test?

Only one CC2652P coordinator is running.

So it is a Zigbee network consisting of only one CC2652P coordinator? No other devices?

I have tested in 2 condition, one is only one CC2652P coordinator but it has recorded some joined node, the other is CC2652P coordinator with 1 Router and 2 End-Device. Both of them have triggered this issue.

I have upgraded coordinator's SDK to 7.41.00.17, this issue can't be fixed.

When the issue happens, what do you see in "nwkDB_t *nwkDataBufQueue;" --> "uint8_t lastCnfStatus;      // The last MAC_MCPS_DATA_CNF status"?

I have not checked the "lastCnfStatus" of "nwkDataBufQueue", but I have count the executing of "ZMacDataReqSec" and "MAC_MCPS_DATA_CNF", their executing counters are not equal.

I find my coordinator can be recovered like this. When the issue happens, force coordinator scan network with "Zstackapi_DevNwkDiscReq", then use "ZMacDataReqSec" to send 256 packets of empty MAC-Data-packet, the "nwkDB_CountTypes" will be recovered to 0.

When the issue happens,  empty MAC-Data-packet can't be sent. But after beacon-scan, empty MAC-Data-packet can be sent.

Hi Aries,

Thanks for the update. I will file a ticket.

Aries Lord said:

I have upgraded coordinator's SDK to 7.41.00.17, this issue can't be fixed.

In the meantime, can you try with 8.30 F2 SDK?

Thanks,
Toby

I have tried with 7.10.00.98 SDK, and this issue has never appeared, my coordinator has been running for a week.

I have move my coordinator's application program (SDK 7.41.00.17)  to CC1352P LaunchPad, and this issue has never appeared too.

That's good to know.

I'll add to the ticket these points:

1. Issue seems SDK dependent (does not happen on 7.10.00.98 SDK)
2. Issue seems HW dependent (does not happen on CC1352P Launchpad, does happen on custom board/module)

I do still recommend to use the latest SDK we have.

I have update the SDK to 8.30, this issue is still appearing.

Thanks for confirming.

I've updated the ticket.