CC1310: CMD_PROP_TX sometimes stuck in ACTIVE (long range mode)

Hei Fredrik,

1) What version of the SimpleLink CC13x0 SDK are you using?

2) We have two errata notes concerning long Rx operations. Can you check whether any of these seem to apply? (Avisory 08 and 09). How long does your device typically stay in Rx before receiving a packet?

https://www.ti.com/lit/swrz062

Cheers,

Marie H

Hi Marie,

1) we are using cc13xxware. The manifest says that all software versions are "3.00.xx".

2) The RX duration depends on the environment, and can be anywhere from a few ms to several minutes. I did have a look at the errata notes, but I am not sure they apply. If I understand these correctly, Advisory 08 and 09 affect the performance of the receiver. Do you think they could be responsible for the behavior I'm seeing?

thanks,

Fredrik

Hi Fredrik.

Is there a reason why you are using cc13xxware? It is a very old release.

The Simplelink SDK is the recommended software development kit and the latest version for the CC1310 device is found here 

https://www.ti.com/tool/SIMPLELINK-CC13X0-SDK. 

Regards,

Sid

Hi Sid,

We mainly use driverlib and the RF patches from cc13xxware. I downloaded SDK v4.20, and it doesn't look like the RF patches have been updated since the version we are using, and the driverlib changes look superficial. Since the RF drivers are basically thin wrappers on top of register read/writes, is there a particular reason why the latest SDK would help in this particular case?

best,

Fredrik

Hi Fredrik,

It is hard to comment on whether this would fix the issue you've seen and might not be relevant. But it can be helpful to include the bug fixes, features, CPE, MCE and RFE patch updates introduced over time. 

You did mention that you were looking into RFCPEIFG, is there any interrupt flag there that is set when you are in this TX state?

Regards,

Sid

Hi Sid,

We are using very little of the driverlib in our RF code. Essentially we are talking directly with the radio core through the doorbell register (following the reference manual for guidance).

No interrupts are raised after the last COMMAND_DONE from the TX frequency step is raised. It would be helpful if I could "poke" the radio core and ask what it's doing in this state.

Thanks for looking into this with me!

best,

Fredrik

Update: I was toying with the radio command chain to understand more of what is going on. I now use the following chain:

• CMD_PROP_RADIO_DIV_SETUP for TX
• CMD_FS for TX
• CMD_PROP_TX with startTime set to the planned transmit time
• CMD_FS for RX
• CMD_PROP_RX_ADV

Whenever the conditions I described initially happen, I observe the following sequence of events:

1. The RAT compare triggers and runs CMD_ABORT
2. Still inside the RAT compare's interrupt handler, CMD_PROP_RADIO_DIV_SETUP is sent to the radio core (which returns CMDSTA_Done)
3. When the interrupt handler returns, IRQ_COMMAND_DONE and IRQ_RX_ABORTED are both pending (because I aborted an in-progress RX, I guess)

After step 3, nothing happens until my debug RAT compare fires 20 ms later. In there, I observe that the CMD_PROP_RADIO_DIV_SETUP command is ACTIVE.

It would seem that _neither_ CMD_PROP_TX nor CMD_PROP_RADIO_DIV_SETUP are able to finish if they are sent after a CMD_ABORT which results in IRQ_RX_ABORTED. I'm still puzzled by this, but hopefully this information will help.

thanks,

Fredrik

I read through the driverlib release notes included in the latest Simplelink SDK version. In the bugfix list for driverlib_cc13xx_cc26xx_3_03_01_18037, the following caught my eye:

• [RF_PATCH] CPE: Updated CPE PROP and CPE multi-protocol patches with bug fix: if a packet is received with a proprietary mode Rx command (CMD_PROP_RX*) and a partial read Rx buffer is used, the CPE will hang if an abort command is received while a packet is being received.

I failed to mention initially that I use a partial read Rx buffer. This sounds like it would explain the behavior I'm seeing. Furthermore, version driverlib_cc13xx_cc26xx_3_04_02_18173 includes the following fix:

• [RF_PATCH] General: CC1312, CC1352: Updated the MCE SimpleLink Long Range ("sl_longrange") PHY patch to fix a potential problem related to stopping the demodulator when using SimpleLink Long Range PHY formats. The problem was that use of CMD_ABORT or CMD_PROP_RESTART_RX to stop an on-going RX operation with this PHY could result in RF core doorbell interface to become unresponsive, and a re-initialization (power-cycle) of RF core would be needed to recover.

Could it be that these bugfixes apply to CC1310 in addition to CC13x2 and CC26x2?

thanks,

Fredrik

Hi Fredrik

Just wanted to let you know that we are working on this, but please allow us some time since we need to dig into old versions of patches etc.

If there any chance that you can set up a small demo code that is showing what exactly you are doing?

I tried to make a small code example setting up a command chain (from how you have explained that your command chain is), and then abort RX after sync has been found (I used RF_EventMdmSoft to trigger a callback so that I knew that sync was found before aborting), but I have not been able to see any issues.

The only thing I did not test was to use the partial read entry, but from the issue you are referring to with partial read entries, my understanding is that this will have the RF core stuck immediately when doing the abort, and not when doing the next command after the abort.

It is kind of hard to debug this when we are not seeing any issues on our side.

I understand that it might take some time to make a small demo code that we can test here, but what you can start with is to re-write your code so that you always do an abort when you are receiving packets. This will make the error trigger more often.

You can then do more testing with slr vs genfsk, to be able to determine if this is only related to slr.

You could also try to use the general data entries instead of the partial rx entries to see if this changes the behavior.

BR

Siri

Hi Siri,

Thanks for looking into this. It looks like the driverlib we are using comes from simplelink_cc13x0_sdk_2_20_00_38, so we should be safe from Advisory 08 and 09. However what I said earlier isn't true:

Fredrik Flornes Ellertsen said:

it doesn't look like the RF patches have been updated since the version we are using

The patches are indeed different, apologies for missing that earlier. Before we dive deep into debugging, let me run the system for a couple days with rf_patch_cpe_sl_longrange.h from SDK v4.20.01.03 (the most recent version of this patch I can find) and see if my problem is resolved with the updated patch.

I'll post here with my results.

cheers,

Fredrik

Hi Fredrik

Looking forward to hear your results :-)

Siri

Alright, I've tested the new RF patches and my issues have disappeared. Very happy about that, but I do wonder why that helped? I can't see any entries in the changelog relating to RF_PATCH on the CC13x0 since the version we were using previously.

cheers,

Fredrik

Glad to hear that the new patches works as expected.

I have reached out to R&D and asked them about the differences between the patches, and will let you know once I hear back from them :-)

BR

Siri

Just one question Fredrik. Did you only change the cpe patch or did you change other patches as well (rfc/mce)

Siri

I updated everything in the rf_patches directory.

best,

Fredrik

Hi Fredrik

Still digging into this. I wanted to see if I could reproduce the error with the old patches that you used originally but I am not able to. 

Could you send me your exact setup for your command chain? SETUP, FS, TX and ADV RX command.

BR

Siri