S120 & nRF51822: Stopping scan kills connections, sometimes

[Chris Hodapp]

What I've been observing here is a curious issue under some very specific circumstances. First off, I am using a Xuntong Tech PTR9018 module (this is QFAAC0), the S120 1.0.0 softdevice, and SDK 6.0.0 (though I first saw this on S120 1.0.0-1.alpha and SDK 5.2.0, and then updated softdevice & SDK). I've been testing with 2 simultaneous connections (one to another Nordic board running S110, and one to a USB BLE dongle).

The specific symptom I am seeing is that connections with peripherals are dying. Doing any of the following things stops these symptoms:

• Enabling the UART, e.g. via simple_uart_config. (This is regardless of whether I use the UART or whether its pins are physically connected)
• Connecting SWD and doing something to put the processor in debug mode.
• Removing all calls to sd_ble_gap_scan_stop() and setting ble_gap_scan_params_t.timeout to something nonzero and then actually reaching that timeout after starting a scan. (This is excluding a call to sd_ble_gap_scan_stop() which happens right before making a connection - modeling after what the ble_multilink_central example does; this call never seems to cause problems.)

Enabling a UART takes my idle power usage from 200 uA up to 1-2 mA, and this won't do for the low-power usage I have here; otherwise I'd just enable the UART and ignore this.

I tested a little to see how far simple_uart_config had to actually run to stop the symptoms. What I found is that it had to get as far as executing NRF_UART0->TASKS_STARTTX = 1.

These symptoms are also quite nondeterministic. I can have several connections in a row work flawlessly; I can have connections stay up for 5-10 minutes. When connections die, it appears to re-establish them fairly quickly.

Does anyone have even a clue what could be going on here?

Update (2014-08-26): The issue appears to actually have nothing to do (directly) with stopping scanning.

It is somehow related to how I'm powering the nRF51822, which is from a Texas Instruments TPS70933 LDO (3.3 V). All of the above symptoms are the same, except that for them to occur, I must be powering it from this LDO, and giving it sufficient input voltage (say, >= 3.4 V) that it is regulating.

I suspected instability in the LDO and checked the capacitances, but I was unable to resolve the issue or to see any clear evidence of excessive ringing or overshoot when looking at the power lines on an oscilloscope. On several occasions, I observed no problems for 2+ hours, and then problems suddenly occur again.

[Stefan Birnir Sverrisson]

Hi

The nRF51822 QFAAC0 is the first revision of the nRF51 chip and has not been tested with the S120 softdevice. The S120 was first introduced for use with the second revision hardware, e.g. QFAAFA, QFAAGC or QFAAG0. You can see this in the nRF51822 compatibility matrix in the nWP-018 v1.3, table 1

[Chris Hodapp]

This chip appears to be working just fine with the S120 softdevice in my own testing. The issues detailed here do not appear to be related, in further investigation.

[Stefan Birnir Sverrisson]

I highly suspect that your problem is related to a bug in the power module of the first revision chip. The bug was dependent on temperature and supply voltage to the nRF51 chip. One workaround to the problem was to have the high frequency clock source constantly enabled. When you enable the UART, you are doing exactly that, i.e. by enabling the UART you also enable the high frequency clock. So, I recommend that you upgrade to the latest nRF51 hardware, then I suspect that your problem will go away.

Update 23.9.2014
The nRF51822 QFAAC0 is the first revision of the nRF51 chip and has not been tested with the S120 softdevice. The S120 was first introduced for use with the second revision hardware, e.g. QFAAFA, QFAAGC or QFAAG0. You can see this in the nRF51822 compatibility matrix in the nWP-018 v1.3, table 1

Anomaly #11 in the nRF51822 PAN v2.3 indirectly addresses this issue. The anomaly is in my opinion not well formulated but it indicates that TIMER operation does not always work when there is no other peripheral on the chip requesting the high frequency clock (HFCLK). The softdevices use TIMER0 peripheral to control timing while the radio is active, so the workaround is to enable constant latency as proposed in anomaly #11 workaround section. A workaround for this was implemented in S110 early versions but was never implemented for S120 as the S120 was never intended to run for the first revision hardware.

A workaround is to enable constant latency which will keep the HFCLK constantly enabled. However, enabling constant latency will add up to 1mA to the average current consumption, which may not be acceptable for a low power application. To compensate for the high current consumption of the constant latency mode, it should be possible to use radio notifications to enable the constant latency mode just before the BLE radio event starts and disable it again as the radio event finishes.

[Chris Hodapp]

Stefan: Thank you. I will try the workaround of having HFCLK enabled. Sadly, we were using a newer revision (the Laird BL-600) and had intermittent connection issues, but only with certain peripherals; this is why we switched to the PTR9018 in the first place.

Is this issue documented anywhere? I looked through nRF51822-PAN v2.3 and did not see anything that sounded like this.