CC1352R: pDataCnfCb (data sent callback) stops returning

Hi Andras,

Thank you for posting, we also got an e-mail from your colleague Astrid.

When this happens, can you restart the device, rejoin the network etc? Or does it not help to restart it?

Please also let me know if you have implemented any handling of ApiMac_mcpsDataReq function returning an error?

Hi Marie,

Thank you for the fast response!

When it happens, the restart of the device helps, i.e. it can send again packets and rejoin to the network.

We don't have any unusual return code from ApiMac_mcpsDataReq but eventually the queue fills up and we start getting the ApiMac_status_transactionOverflow  status code from ApiMac_mcpsDataReq.

Best regards,

Andras

Hi Andras,

Can you please test the following and retry?

Can you ask them to try setting this parameter to zero and trying it? FHPIB_CSMA_BASE_BACKOFF = 0?

Hi Marie,

Unfortunately, setting it to 0 does not solve the issue, it still shows up. (ApiMac_attribute_maxCsmaBackoffs)

Best regards,

Andras

Hi Andras,

I see.

I am aligning with Jörgen on next steps.

Hi Marie,

Again, thank you for your quick response and for looking into the issue we have seen!

Attached to this forum post you will find an archive which contains the information needed to modify the sensor and collector examples from Simplelink CC13x2 26x2 SDK 4.40.04.04 in order to reproduce a scenario where the data confirm callback is no longer called.

Best regards

Jakob Ruhe

2021-02-09-sensor-collector-fh-async.tar.gz

Hi Jakob,

Thank you for uploading.

As we agreed in the call, we will try to reproduce and root-cause the issue on our side.

Hi

Is there a solution or workaround to this problem?

I see the same issue in my application: the Sensor device stops transmitting once the MAC queue gets full and all further data requests fail with status of 0xf1 (overflow). I am using CC1352P with Ti154 stack in 915Mhz band

-Thanks, Joseph

Hi Joseph,

We are currently working on finding the root cause for this issue. As far as I know the only work-around is to reset the device.

Hi Marie,

Thank you for your time and effort that you spend on this issue.

We have been looking into it and it get to the conclusion that indeed in the simple example  -that we sent you - the channel list is not defined when the async request is submitted. If we define a channel list for the async request the issue does not pop up.

However, in our firmware we always define a channel list for the async requests and the issue still appears. We are trying to reproduce the issue with TI's sensor and collector applications once again but with defined channel lists for the async requests.

Best regards,

Andras

Hi Andras,

Ok I understand. 

Please let me know when you are able to reproduce with these examples.

Hi Marie,

We managed to reproduce the original issue nonetheless with the channel list included. Please follow this simple step to replicate the problem:

• Unplug the collector after the connection is established. (This will trigger re-transmissions.)

Best regard,

Andras

Hi Marie,

We tested the suggested solution both with TI's collector and sensor applications and with our firmware and unfortunately the issue still showed up.

I am sending a new version of sensor and collector applications that can be used to reproduce the problem easily. (We used these on top of the SDK changes that Jörgen suggested)

Best regards,

Andras

2021-04-01-sensor-collector-fh-async.zip

Part Number: CC1352R

Hi Marie,

Sorry for the late answer.

We tried the potential fix but unfortunately it did not solve the issue.

Best regards,

Andras