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 your suggestions.

For the 1st issue we have ACK's disabled in esb and only use the no-ack branches.  Slave processes each request via a callback as soon as the packet has arrived.  The periodic packet with 2-byte payload instead of 1-byte payload from Master to Slave (with no response from Slave) has continued to prove successful in avoiding radio lock-up on the Slave side.

We've resolved the 2nd issue, it appears.  We stopped pushing the Master's radio from active receiving "RX" state to "RXDISABLE" when things go awry, and instead just allow Master's radio to finish receiving any errant packets.  The radio no longer locks up.  Not yet anyway.  I also checked the Master's receive buffer size and it is sufficiently large enough to accommodate any size incoming packet.

Tommy

[Håkon Alseth]

Hi Tommy,

 

 

Thomas_E said:

For the 1st issue we have ACK's disabled in esb and only use the no-ack branches.  Slave processes each request via a callback as soon as the packet has arrived.  The periodic packet with 2-byte payload instead of 1-byte payload from Master to Slave (with no response from Slave) has continued to prove successful in avoiding radio lock-up on the Slave side.

 By going from 1 b to 2 b payload, you're adding a bit of time to the whole transaction, which indicates that the timing is a bit too tight. I'm glad to hear that you found a workaround, although; it seems that the issue is still present.

Thomas_E said:

We've resolved the 2nd issue, it appears.  We stopped pushing the Master's radio from active receiving "RX" state to "RXDISABLE" when things go awry, and instead just allow Master's radio to finish receiving any errant packets.  The radio no longer locks up.  Not yet anyway.  I also checked the Master's receive buffer size and it is sufficiently large enough to accommodate any size incoming packet.

Good to hear! Let me know if any other issues/questions comes up.

 

Cheers,

Håkon