NRF51822 boards with bluetooth connection issues are fixed with soft reset but not pin reset

[youngwallaby]

Hello,

The current project I am troubleshooting includes an NRF51822 chip. The project includes a boot loader, application hex, and soft device S110 V7.3.0. It was noticed by the manufacturer that about 5% of the boards experience a dropping of the Bluetooth connection randomly. These boards that experience the connection dropping continue this behavior after being reprogrammed and power cycled. The only way we have found to fix it is to perform a "soft reset" using the nrfjprog command line tool. this soft reset will cause the board to stop dropping the Bluetooth connection until the next power cycle where it begins with the old behavior. Both the pin reset on the chip and the pin reset command on the command line tool were not able to replicate this fix as the soft reset did. 

I know there are function that would allow us to perform a soft reset from within the application, say on first power up write to EEPROM and then do a soft reset. second power up read EEPROM and then continue with normal functionality. I am looking for a more permanent solution for this problem. Any suggestions?

Thanks,

[awneil]

To find a solution, you first need to find what the actual problem is!

Instrument you code, and look for what's different between the two situations.

youngwallaby said:

perform a "soft reset" using the nrfjprog

What, exactly, do you mean by that?

youngwallaby said:

a dropping of the Bluetooth connection randomly

And what, exactly, is going on there?

Are there any other issues with these units - such as low received and/or transmitted power? Oscillator stability/accuracy? etc ...

With any radio link, you have to be prepared for it to drop "randomly" - is your real problem that it doesn't recover after dropping?

[youngwallaby]

Awneil,

The soft reset is described in the nrfjprog command line toolkit: 

nrfjprog -r : performs a soft reset by setting the SysResetReq bit of the AIRCR register of the core. The core will run after the operation.

device connected is an IPhone application. The system does recover the connection after a span of 1-3 seconds. This problem does not exist in the other 95% of the product. A bluetooth signal strength application was installed on an Android device. The signal strength does not appear to be any less than the 95% of units that do not present this problem.

The oscillator was probed on a "bad" unit and it appeared to be operating normally. Could it be that the oscillator is the issue? We could try replacing the component.

Thank you for your feedback

[Jared]

Hi,

Could you provide the datasheet for the crystals that you're using? What sniffer have you used? Could you provide a sniffer trace that uses the nRF sniffer? The sniffer log you attached doesn't showcase the issue, and the connection in the log is disconnected after a disconnect is sent by the host. 

regards

Jared 

[youngwallaby]

Jared,

Attached are the datasheets for the crystals.

I used the Bluetooth snoop hci log feature of androids development tools. We currently do not have a nRF sniffer but can acquire one if that is necessary.

ABS06-107-32.768kHz-T.pdfc_NX2520SA-STD-CSW-4_e.pdf

[Jared]

Hi,

Please provide a sniffer trace with the nRF Sniffer if possible. Could you try changing the LFCLK source to the RC oscillator and see if the problem persist?

Jared 

[youngwallaby]

Jared,

I have captured a sniffer trance with the NRF Sniffer as described in the nRF Sniffer user Guide v2.2 document. That file is attached here: NRF Sniffer Trace.pcapng

I will try changing teh LFCLK source to the LFCLK to the RC oscillator and let you know if that fixes the problem.

Thanks,

[Jared]

 Hi,

Thank you for the sniffer trace. I can't see that the slave doesn't respond to packages with eventually causes a timeout. Did you try changing the LFCLK source? What PPM value do you use in the  sdk config file? Are you able to replicate the issue with an example from the SDK, such as ble_app_uart example? 

regards

Jared 

[youngwallaby]

Jared,

I wanted to share what I found to be the problem. It looks like the sleep mode for this unit was not configured properly. Of the two sleep modes, Constant latency and low power, neither were explicitly chosen. Once the sleep mode constant latency was chosen and the boards were reprogrammed the issue with the bluetooth connection dropping went away. 

Thank you for all of your help,