NRF51822 TWI Master (Software) results in BLE Disconnects

[Adrian Eggenberger]

Hi

I've a reproducable behavior i'm not able to explain. I'm using the softdevice S110 6.0 on a nRF51822.

The firmware implements some BLE profiles and uses TWI Master with the software TWI master driver from the SDK. The reason for using the software TWI driver and not the hardware driver is, that we need a lower baudrate than 100kBit/s.

As everything for BLE happens in interrupt context and all operations of the software TWI driver in normal context i wouldn't expect TWI to have an influence on BLE. But when a BLE connection is established the TWI communication kicks in and in most cases the BLE connection disconnects with reason "BLE_HCI_CONNECTION_TIMEOUT". I wouldn't expect that, because the bitbanging TWI shouldn't have an influence on the BLE implementation, that runs in Interrupt context.To make things even more strang the misterious disconnects disappear if i'm connected to the debugger (that makes the debugging a bit difficult).

Any idea how to fix this problem or to get more information on the behavior?

Rgards Adrian

[Ole Morten]

This sounds a little odd, and I can also not quite understand how this happens. The only thing I can think of is a HardFault or similar, but this should be visible when letting the chip run freely in debugger mode, and then stop it when the timeout happens.

If you can supply your complete code project, I'd be happy to take a look on it, and try reproducing the problem. You can either edit your question and add an attachment, or post a regular support case with it.

[Adrian Eggenberger]

The behavior is really odd, but the solution is easy. It turned out, that the supply voltage was the problem. There was a lot of noise on it, but it never gets below 2.4V. Adding a capacity to the supply voltage did fix any curious behavior. So the problem is fixed, but it would be interesting, why the noise on the supply may lead to disconnects even when the voltage remains in normal range.

[Ole Morten]

The general recommendation is to make sure the ripple on VDD is less than 100 mV. I'm not sure what kind of effects ripple above this will have on the chip, but it could be that it can affect the stability or startup times of the oscillators, which in turns may ruin the BLE link. When debugging, the 16 MHz clock will be continuously running, and hence may mask such issues.

Anyway, great that you found a solution and posted it! I'll definitely keep it in mind for future cases and questions!