CC2652R: RX fails using TI Simplelink SDK 8.30.01.01

Martin Meier

Part Number: CC2652R

Hello!

We have encountered a problem with our application running as a TI15.4 Coordinator using TI Simplelink SDK 8.30.01.01.

In the current setup only one channel is configured, which means that no CCA measurements are being made.

After ~30mins of quite heavy 15.4 traffic to the coordinator the stack stops responding. No callbacks are fired, it does not respond to UHF Scan. In this scenario, if I manually trigger a CCA (energy detect scan through ApiMac_mlmeScanReq) the stack recovers, meaning it responds to UHF scans, callbacks are fired on incoming messages and so on.

Now, here's the interesting part: If I upgrade the application to TI Simplelink SDK 8.31.00.11 I can no longer reproduce the issue. This brings me to the question:

Is this something you have discovered and fixed in 8.31.00.11?
I can't find anyting in the 8.31.00.11 changelog that matches this behaviour.

1 month ago

0 Daniel Guarecuco Aguiar 1 month ago

TI__Expert 6457 points

Hi Martin,

Are you referring to a Zigbee Coordinator or a TI 15.4-Stack Collector? Is the example taken from the zstack or ti154stack folder?

I see you are linking to a DMM thread, are you running DMM?

Best regards,

Daniel

0 Martin Meier 1 month ago in reply to Daniel Guarecuco Aguiar

Prodigy 65 points

Hi Daniel,

This is the same application as in the references thread. So, I am running a DMM, the device is setup as a coordinator on the network and I believe the example is taken from the ti154stack.

0 Daniel Guarecuco Aguiar 1 month ago in reply to Martin Meier

TI__Expert 6457 points

Hi Martin,

I can see that an issue (TI154STACK-4484) fixing a memory corruption in heap was fixed in version 8.31.00.11 TI 15.4-Stack 7.31.00.00 Release Notes.

That was originally reported in the other thread CC2652R: DMM with BLE Peripheral + Ti15.4 Coordinator - how to send frames longer than 125 bytes - Zigbee & Thread forum - Zigbee & Thread - TI E2E support forums

I think might be a related issue.

Best regards,

Daniel

0 Martin Meier 1 month ago in reply to Daniel Guarecuco Aguiar

Prodigy 65 points

Hi Daniel,

Ok, do you suggest that such memory corruption would recover by triggering a CCA energy detect scan?

0 Daniel Guarecuco Aguiar 1 month ago in reply to Martin Meier

TI__Expert 6457 points

Hi Martin,

I'm not quite sure. Not saying it is the same issue, but possible related. Maybe the energy scan hits a recover mechanism. Some other issues were fixed as documented in the release notes.

What is the intention? Would you like to remain on SDK 8.30? Or is moving to 8.31 ok?

Best regards,

Daniel

0 Martin Meier 1 month ago in reply to Daniel Guarecuco Aguiar

Prodigy 65 points

Hi Daniel,

Thank you for reply. We want to confirm that the issue we are facing is indeed resolved in the 8.31 SDK. So far we have not seen the issue with the same setup with 8.31, but that's a vague confirmation. So the intention is to check with you to verify that the issue has been fixed in 8.31.

0 Daniel Guarecuco Aguiar 1 month ago in reply to Martin Meier

TI__Expert 6457 points

Hi Martin,

Ok, I don't have a way to easily replicated your issue.

You could try to copy the macTask.c from the 8.31 SDK into your CCS project folder, copying it into the 8.30 SDK might not do anything as the project will use the precompiled lib .a

<SDK_8_31>\source\ti\ti154stack\common\osal_port\osal_port_posix\macTask.c

Best regards,

Daniel

0 Martin Meier 1 month ago in reply to Daniel Guarecuco Aguiar

Prodigy 65 points

Hi Daniel,

Thanks.

I have prepared the macTask to our test as you suggested. Will get back to you, hopefully within a few days, with a result.

/Martin

0 Martin Meier 1 month ago in reply to Martin Meier

Prodigy 65 points

Hi Daniel,

I setup a test as per your suggestion where macTask.c taken from 8.31 is placed in our 8.30 CCS project folder, and the locationURI in .project-file is modified to reflect the project location for macTask.c. Unfortunately the problem persist, i.e. the stack stops responding.

Not sure what this gives us in terms of confirming the issue? However, we are quite confident that the upgrade to 8.31 solves the problem. I don't think we need to spend more time on this.