CC1310: RX freeze with buffer in BUSY state

Matteo Foppiano

Part Number: CC1310

Hi,

I'm using NoRTOS without EasyLink, with proprietary radio commands.

I have the device set in reception, the buffer is submitted to the RX core with the correct state PENDING (0). None is sending data to the device, but after some minutes (time is variable) the state of the pending buffer is BUSY (2) and remains BUSY, if some other device send something it is not received (RX is freezed).

If I cancel the pending RX action with RF_cancelCmd(XXX, YYY, 1), the function returns no error but further commands submitted to RF core doesn't work. If I use RF_cancelCmd(XXX, YYY, 0) to cancel the RX action, further commands works fine.

When this problem doesn't happen (i.e. the pending buffer isn't "corrupted"), the RX works fine.

I can't paste the code here because it is quite large, I'm trying to extract a small version that presents the problem.

Has this problem ever occurred to anyone? Maybe someone can point me in the correct direction to debug this problem.

Thank you

over 4 years ago

0 Siri over 4 years ago

TI__Guru* 86241 points

It is hard to answer this without seeing your code and the possibility to try to reproduce the problem myself.

I guess there is a lot of other stuff going on in your code except the RF part. It is therefore a good ide to try to make a simple test program that only do RF, to see if you can reproduce the problem. This code you would probably also be able to share with us, so that we could help with debugging.

I would recommend that you take the rfPacketRX example from the latest SDK and modify it to run the way you are doing RX in your application.

You are saying that your data entry becomes BUSY even if you are not transmitting anything (You do not say anything about which data entries you are using or how you are handling them). I assume that if you are transmitting data, everything works as it should? This indicates that your code is not built to handle packets that are not of the format you expect.

After making a small RX test code, you should therefore try to send packets of different format to see if you can make it fail. That could be packets that are longer than what you normally send, packets with wrong address (if you are using address filtering), packet with CRC error etc.

Also note that cancelling the RX command only takes care of the RF Core. You must also clean up your data entries (since they have obviously received something) before starting RX again.

0 Matteo Foppiano over 4 years ago in reply to Siri

Prodigy 160 points

Hi,

I've reduced the code at the minimum, you can find it attached.

The code simply stay in RX, and every 10 seconds (more or less), it stops the RX and send a packet, then RX is restarted.

The RF is used in 802.15.4g mode;
I use GCC ARM 10-2020-q4 to build the code;
for board initialization I kept the same files used in TI's examples (CC1310_LAUNCHXL.c/...).

I put this code on a CC1310_LAUNCHXL and use another CC1310_LAUNCHXL with "Packet RX" function of SmartRF Studio to receive data sent by the first board. After some minutes (usually less than 1 hour), the first board that is sending data "freeze" and no more data is sent.

Thank you

test_rf.zip

0 Siri over 4 years ago in reply to Matteo Foppiano

TI__Guru* 86241 points

I have your code up and running and I can receive the packets it sends with SmartRF Studio.

However, I am not able to receive anything with the code while in RX. How can I configure SmartRF Studio to transmit packets that will be received with your code?

Siri

0 Matteo Foppiano over 4 years ago in reply to Siri

Prodigy 160 points

Siri said:

I have your code up and running and I can receive the packets it sends with SmartRF Studio.

Ok very good. Theoretically leaving the boards running in this situation, you should see that after some time the SmartRF Studio doesn't receive any new packet.

Siri said:

However, I am not able to receive anything with the code while in RX. How can I configure SmartRF Studio to transmit packets that will be received with your code?

The code configure RF to use addresses of 2 bytes, and in the code the address configured for reception is 0x03ff.

0 Siri over 4 years ago in reply to Matteo Foppiano

TI__Guru* 86241 points

Just wanted to let you know that I have been able to reproduce the issue you are seeing with a small demo code I made myself.

I am in the process of getting help to debug this, and will keep you updated.

It is correct that when you cancel the RX command abruptly, you do not see any issues. Is that correct?

Siri

0 Matteo Foppiano over 4 years ago in reply to Siri

Prodigy 160 points

Hi,

Siri said:

Just wanted to let you know that I have been able to reproduce the issue you are seeing with a small demo code I made myself.

I am in the process of getting help to debug this, and will keep you updated.

Thank you very much for support.

Siri said:

It is correct that when you cancel the RX command abruptly, you do not see any issues. Is that correct?

If I use the RF_cancelCmd(XXX, YYY, 0) the cancel works fine, but if in the meantime the RX is stuck, it remains stuck until I cancel it (so I'm not be able to receive data until I cancel it and restart the RX).

Thank you

0 Siri over 4 years ago in reply to Matteo Foppiano

TI__Guru* 86241 points

Thank you for the additional info.

When you say "but if in the meantime the RX is stuck, it remains stuck until I cancel it", has it become stuck without trying to do a RF_cancelCmd(XXX, YYY, 1), or have you done RF_cancelCmd(XXX, YYY, 1), RX gets stuck, and then RF_cancelCmd(XXX, YYY, 0) fixes it again?

What we are trying to figure out is if RF_cancelCmd(XXX, YYY, 1) is causing the RX to get stuck, or if RX gets stuck for some other reason, and RF_cancelCmd(XXX, YYY, 0) fixes it, while RF_cancelCmd(XXX, YYY, 1) does not.

Siri

0 Siri over 4 years ago in reply to Siri

TI__Guru* 86241 points

Hi again

I reached out to R&D regarding the issue, and I think they have found the issue.

The setup you use are altered from our recommended 802.15.4g settings, and contains an untested combination of 15.4g configuration and address to be handled by the RF core. In the 15.4g setup, there is support for a special packet type called mode switch. In practice, I think this packet type is deprecated, but the point is that the header bits mean something else, and there should be no payload. This is signaled in the first bit of the header, and if this is 1, the radio assumes that the payload length is 0 without further check of the rest of the header. When address is used, it is normally checked that the received payload length is large enough to hold the address, but this check is not done for mode switch packets. When the payload is too short, the receiver gets stuck in the address RX state. This happens regardless of whether the stop command is sent, which means that the receiver will hang. An abort gets it out of the hang.

The way to fix this issue is to disable the mode switch packet support. This is done by adding the override 0x00FE8A53. Note that this override should only be added when 15.4g is configured.

I will do some additional testing with this override, but I cannot do it before later today. It normally does not take too long to get the RX to hang, so I will leave my test code running over nigh, and see if it still is OK tomorrow morning.

Siri

0 Matteo Foppiano over 4 years ago in reply to Siri

Prodigy 160 points

Siri said:

Thank you for the additional info.

When you say "but if in the meantime the RX is stuck, it remains stuck until I cancel it", has it become stuck without trying to do a RF_cancelCmd(XXX, YYY, 1), or have you done RF_cancelCmd(XXX, YYY, 1), RX gets stuck, and then RF_cancelCmd(XXX, YYY, 0) fixes it again?

For what I can see it get stuck BEFORE issuing the RF_cancelCmd(XXX, YYY, 0).

Siri said:

What we are trying to figure out is if RF_cancelCmd(XXX, YYY, 1) is causing the RX to get stuck, or if RX gets stuck for some other reason, and RF_cancelCmd(XXX, YYY, 0) fixes it, while RF_cancelCmd(XXX, YYY, 1) does not.

I see, but for what I can see from my investigation the RF_cancelCmd() doesn't cause the problem, the problem has already happened.

Thank you

0 Matteo Foppiano over 4 years ago in reply to Siri

Prodigy 160 points

Ok, clear. I will try to disable mode switch too and check if it works fine.

It is not a problem if you can't make the tests until later today, even tomorrow is fine.

Thank you very much.

0 Siri over 4 years ago in reply to Matteo Foppiano

TI__Guru* 86241 points

I had my test running for 15+ hours with the new override. I tried to cancel the RX command nearly 200000 times using RF_cancelCmd(XXX, YYY, 1), and I did not experiencing any problems.

Siri

0 Matteo Foppiano over 4 years ago in reply to Siri

Prodigy 160 points

Thank you very much for the investigation and the fix.

You wrote "...this is done by adding the override 0x00FE8A53. Note that this override should only be added when 15.4g is configured".

It is ok to put the override in the pOverride used by radio setup command (after the other overrides for 802.15.4g)? Or do I have to apply that override after the RF_open() returned?

Thank you

0 Siri over 4 years ago in reply to Matteo Foppiano

TI__Guru* 86241 points

You simply apply it to the bottom of your override list, just before the 0xFFFFFFFF override:

    .
    .
    .
    // override_crc_ieee_802_15_4.xml
    // IEEE 802.15.4g: Fix incorrect initialization value for CRC-16 calculation (see TRM section 23.7.5.2.1)
    (uint32_t)0x00000943,
    // IEEE 802.15.4g: Fix incorrect initialization value for CRC-16 calculation (see TRM section 23.7.5.2.1)
    (uint32_t)0x00000963,
    // TX power override
    // Tx: Set PA trim to max (in ADI0, set PACTL0=0xF8)
    ADI_REG_OVERRIDE(0,12,0xF8),
    (uint32_t)0x00FE8A53,
    (uint32_t)0xFFFFFFFF
};

Siri

Sub-1 GHz

Sub-1 GHz forum

CC1310: RX freeze with buffer in BUSY state