nRF8001 freezing

[David]

Hello,

In a quite particular configuration, the nRF8001 sometimes stops responding. The only way to make it work again is to do a hardware reset using the reset pin of the transceiver. Is there a workaround to prevent the freezing?

HW-Setup: MSP430 as a master device on the SPI bus. nRF8001 module by Insight SIP (ISP091201)

How to reproduce the problem: Using the HID setup of our device, we pair with a mobile phone (e.g. iPhone SE (2018), iOS 14.1). Then a new setup for unpaired connections without security is loaded. The new setup contains several proprietary services that are completely different from the previous HID service. Seeing the same MAC address, the phone tries to restore the connection with our device but disconnects after about seven connection intervals. The MSP430 reads the dynamic data and restarts the advertising for a new connection (still without pairing). The phone recognizes the address and connects again... After some iterations of this process, there is no more connection (active signal not available anymore) and the nRF8001 becomes unresponsive. It doesn't accept new commands anymore. When pulling nREQUEST line to zero, the nRF8001 will not pull the nREADY line to zero. The last successful command is a connect-command that is confirmed by a command response event (without error) sent by the nRF8001.

I will attach a compressed trace of the Saleae logic analyzer containing all relevant signals7450.nRF8001_freeze_20201124.zip

A simple solution is to delete the bonding information of the phone which then stops its connection attempts. This works, but the goal is to have a foolproof device with the nRF8001. Did we miss out on something? Any suggestions?

Best regards
David

[run_ar]

Where in the logic trace do the chip fail to respond? is it only at the end of the logic trace where the REQN line is pulled low, or are there other occurrences?

Could you add a workaround for Anomaly 7, so that you have a delay before you start advertising PAN025 Product Anomaly Notification v1.5. Not sure if this is related, but if I remember correctly it could lead to the chip not responding in case the random numbers do not generate fast enough for the advertisement to start within a certain period. Are you testing this at room temperature?

Also there are several occurrences in the trace that shows the master sending a connec command in the middle of the read dynamic data command resulting in the nRF8001 nacking this command (all the 0x83 on the right side are nacks / ACI_STATUS_ERROR_DEVICE_STATE_INVALID):

[David]

Hello run-ar,

The only failure occurs at the end of the logic trace. At about 246s from start, NREQ is pulled low by the controller, but the nRF8001 does not respond (NRDY stays high).

The trace was recorded at room temperature and the nRF8001 is not in sleep mode (condition for PAN_025 #7 ?). However, when printing additional debug information on a serial interface the freezing does not occur. Maybe the delay introduced by doing so is sufficient for the RNG. What is the expected delay at room temperature?
We will check what happens with a delay before issuing the connect command.

You are right, the controller should wait for the end of the transmission of dynamic data before sending another connect command. Thank you for pointing out this error.

[run_ar]

At room temperature it would typically need about 128 ms to generate the random numbers needed to start advertising.

[David]

Hello run-ar,

Even if the nRF8001 is not in sleep mode we added a delay of about 130 ms before each connect command. Unfortunately, it still freezes after some time. See the new trace from Saleae logic analyzer. The freezing occurs at the end of the trace at about 174.3 s where the NREQ signal is pulled low...

nRF8001_freeze_20201202.zip

At 47.75 s there is a hardware error event, related to file ll_lm.s0.c at line 0x3b02. Is this an indicator of some misuse?

Best regards
David

[run_ar]

Hi,

Do you have a sniffer trace that shows if the device starts advertising, and if there could be a connection request from the peer?

Do you monitor the active signal? If so, would it be possible for you to reset the chip if there is no activity on the active line for a given period of time?

I am wondering if you could be hitting pan issue 6 as I am not sure the problem description is correct for this one. Still looking at our issues database, but I think there is a state where the chip could become unresponsive due to this issue, so it is recommended that the application mcu monitors the active line so it can reset the chip using the reset line in case the chip becomes unresponsive. However the active line will only be toggled if the advertisement interval is slower than 30 ms.