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,

Are you able to provide a sniffer trace of the connection between the faulty unit and the Iphone? Could you share the schematics and layout files of the custom board, and also specify which crystal that you're using.

regards

Jared 

[youngwallaby]

Hello Jared,

I will capture the sniffer trace of the connection shortly. In the mean time I have the schematic attached below. The 32kHz crystal being used is a Abracon Corporation ABS06-107-32.768KHZ-T. The 16MHz crystal being used is a NDK NX2520SA-16MHZ-STD-CSW-4. I will request the layout files and get those to you as well.

Thanks,

[youngwallaby]

Here is the Bluetooth log file:

 6740.btsnoop_hci.log

[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