Operand Error (OPERR flag) from radio module

A bit late answer, but for future reference for others.

The FUG says it better than me what causes OPERR, and it also says that due to the radio core possible being in the middle of executing an instruction when this occurs, the radio core might be in an unpredictable state. I interpret this as a full reset of the radio core, and subsequently a re-configuration to previous settings, as the best thing to do in this situation.

Although, I occasionally get this too, and even though I strobe flush fifos, strobe reset, writes 0 to all RF1A-registers to clear any pending flags and error conditions and allow sufficient time for radio core bootup and stabilization, the errors actually persist and are still present even after this. Does anyone know why?

Hello Marcus,

According to the CC430F5137 spec, the Vcore range PMMCOREVx should be at least 2 during RF transmissions.

However, I've noticed that when I try to raise it to level 2 before each transmission, it fails – so actually I perform all transmission while PMMCOREVx = 0.

I believe it causes some weird effects we notice from time to time (there are some processor units which are more prone to errors than others) such as:

1. sometimes we notice corrupted 2 bits of the received packet.
2. When requesting to read status bits from the RF module (gdo_state = ReadSingleReg(IOCFG2)) - a respond never arrives, and errors appear (such as LVERR (Low Core voltage), OUTERR (Output data not available), and sometimes OPERR (Operand error).

Do you encounter similar issues?

Lior. 

Hi,

I've taken another approach; I set it to 2 at boot up and keep it there. Not power-ideal but until I have stable radio comms I want to exclude all other possible sources of error. I do check between transmissions and yes, it is set to 2 and stays that way so no surprise there. The power supply is a stable 3.5V and there are large caps on the DUT to handle power consumption spikes. I did actually run with VCORE = 1 for a while with no significantly lesser performance than now..

No, I don't think I've seen any two corrupted bits like you have, however I am using a low-power duty cycling protocol that does repeated transmissions for each packet so it might actually be the case in one or more of the ca 15 transmissions but they are dropped at a low level due to failing CRC at radio level or dropped (due to decryption fail) before they reach the application layer. I do see the LVERR set even though I use VCORE 2, but that's described in the errata as a known error.

If you, like me, put the mcu into LPMs, there are two more things to think of: if the radio is in state transition (between certain states) you must not enter LPM until the state is reached (RF_RDY bit, see the FUG), and the "PMM allow peripherals to request high power bit" must be set (both see p674 in the FUG).

My problems are different. I apparently can't reset the radio core to a blank, fresh state. I now have an extremely aggressive reset function that runs after each transmission that strobes flush fifos, strobes reset, writes to all error and IFG registers (which should reset them) and finally writes the config we have from RF studio. Problem is, the errors persist over all this, time after time. Have you had this problem?

I think it is similar after experiencing scenario #2 I've described (a respond never arrives from ReadSingleReg(IOCFG2)) - and various errors appear).

From this state, If I just timeout from the status read & and continue the execution, the RF never recovers. In my case, I perform a POR, and after power up everything is normal again (until next time....).