Radio lock-up

[Thomas_E]

Hi,

Using 52833 it seems that sometimes the radio quits responding, ie, it is in NRF_RADIO_STATE_DISABLED state and there is

no obvious way to get it out of that state except for NVIC_SystemReset() call.

It usually happens when the radio is under stress, lots of interference and dropped packets.  In general it is a relatively rare occurrence,

somewhat hard to reproduce.  I can sometimes get it to happen in a debug setting if I take the development board and physically pinch the antenna with

my fingers firmly, and place the 2nd communicating development board a little distance away.

But it also happens from time to time in the field with our boards inside a protective casing.

We are using esb with some of our own modifications to the esb library - could we be writing a radio register at the wrong moment

or some other illegal operation that could cause the radio to lock up ?

Can the radio hardware lock up independently of software behavior, if the radio is bombarded with enough interference or errant packets ?

Thank You

Tommy

[Thomas_E]

Hi Håkon,

Thank you for asking.

Not entirely resolved.

We actually have 2 contexts where this issue presents itself:

1) Master transmits a packet with 1-byte payload to Slave on a periodic basis.  Slave does not respond, only receives.  Eventually the Slave's radio locks up.

If instead the Master sends packet with 2-byte payload then the Slave's radio does not ever lock up.

So this problem seems to be solved, though we don't know why 2-byte payload solves it.  Probably something more subtle in our handling of the radio that we have not uncovered.

2) Master and Slave are continuously sending packets back and forth, with somewhat tight timing constraints.  Master always initiates with a small request packet, then Slave sends a larger data packet.  Our connection interval is 1.5 milliseconds.

If there is too much interference for too long, the Master's radio will lock up.  The only thing unusual that we do is that sometimes the Master is receiving a lengthy data packet which unexpectedly spills over into the subsequent connection interval, and so we push the Master's radio from active receiving state "RX" to "RXDISABLE" to cut off the errant run-away packet.  This appears to be legal from the radio state machine diagram.

So we are otherwise still investigating the cause of this lock-up.   Have not found anything out of the ordinary yet with regard to timers / ppi / pertinent radio registers, but we could certainly be missing something.

How long should we wait between powering off and powering on the radio, if we resort to that measure ?

Tommy

[Håkon Alseth]

Thomas_E said:

How long should we wait between powering off and powering on the radio, if we resort to that measure ?

 One 16M cycle (62.5 ns). You can generate such a wait condition by reading any events register, (void)NRF_TIMER3->EVENTS_COMPARE[0];.

 

Thomas_E said:

1) Master transmits a packet with 1-byte payload to Slave on a periodic basis.  Slave does not respond, only receives.  Eventually the Slave's radio locks up.

If instead the Master sends packet with 2-byte payload then the Slave's radio does not ever lock up.

So this problem seems to be solved, though we don't know why 2-byte payload solves it.  Probably something more subtle in our handling of the radio that we have not uncovered.

This sound like a timing issue, do you allow the slave to process the request?

Do you dynamically upload a ACK-payload when the slave receives a payload? If so, there's a very small window of opportunity where the ACK will actually go out on-air.

I would strongly recommend that you always send a payload to let the slave prepare for ACK payload, then a new dummy-payload to fetch it.

 

Thomas_E said:

2) Master and Slave are continuously sending packets back and forth, with somewhat tight timing constraints.  Master always initiates with a small request packet, then Slave sends a larger data packet.  Our connection interval is 1.5 milliseconds.

If there is too much interference for too long, the Master's radio will lock up.  The only thing unusual that we do is that sometimes the Master is receiving a lengthy data packet which unexpectedly spills over into the subsequent connection interval, and so we push the Master's radio from active receiving state "RX" to "RXDISABLE" to cut off the errant run-away packet.  This appears to be legal from the radio state machine diagram.

 Does your buffers allow for such spills?

 

Kind regards,

Håkon