S120 & nRF51822: Stopping scan kills connections, sometimes

RE: S120 & nRF51822: Stopping scan kills connections, sometimes

Chris Hodapp — Fri, 05 Sep 2014 17:25:46 GMT

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.

RE: S120 & nRF51822: Stopping scan kills connections, sometimes

Stefan Birnir Sverrisson — Wed, 27 Aug 2014 12:44:49 GMT

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.

RE: S120 & nRF51822: Stopping scan kills connections, sometimes

Chris Hodapp — Tue, 26 Aug 2014 14:52:57 GMT

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.

RE: S120 & nRF51822: Stopping scan kills connections, sometimes

Stefan Birnir Sverrisson — Tue, 19 Aug 2014 13:09:15 GMT

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