TWI locks on nRF51822 v3

[martin]

hello,

i am experiencing issues with the TWI library on the smart beacon kit rev. 1.3.0 which features the v3 of the nRF51822. i had the same experience on the new nRF52840(preview devkit) but it is not happening as often there.

doing some research i stumbled upon several issues with the TWI driver/peripheral and also found out that there was indeed a lockup problem which, however, should be fixed with the current silicon revision.

TWI module lockup still present in nrf51822 v3-pan-56

TWI stuck and blocked [closed]

TWI issue ? [closed]

Possible bug: I2C stuck

we're using:

• nRF5_SDK_12.3.0
• nRF51822 (Smart Beacon Kit v 1.3.0), latest revision v3
• nRF52840 (Bluetooth 5 preview kit)

the problem appears in nrf_drv_twi.c, line 561

while (twi_transfer(p_twi, &p_cb->error, &p_cb->bytes_transferred, (uint8_t *)p_data, length, no_stop))
{}

one workaround mentioned in the other issues was to use the DMA mode - which is not available for the nRF51 (at least not in the SDK v12.3). are there any updates on that?

the device we're creating will be under heavy stress (vibrations, movement, etc.) so the I2C should be quite stable -- or at least we should be able to recover from issues w/o a restart (we'd lose the bluetooth connection).

any ideas on how to proceed? i really want to avoid using bit-banging.

[martin]

attached screenshot - TWI goes down 2017-08-01_twi_errtrace.png

attached trace from saleae logic 2017-08-01_twi_errtrace.csv

attached logicdata 2017-08-01_twi_errtrace.logicdata

[endnode]

Just a basic sanity check:

• Is your nRF51 I2C master or slave?
• Do you have proper pull-up resistors on the wires?
• You say "TWI goes down" in the first screenshot but there it seems that two characters (Write + Address + one byte) are transferred properly. What exactly is the failure?

In general I2C slave had troubles on all nRF51 revisions to run stable while there is BLE connection ongoing, only TWI (I2C) Master has dedicated HW to survive in such conditions...

[martin]

• the nRF is the I2C master, only one slave connected.
• 10k pull-ups are used for SDA/SCL (the slave is supplied by the same 3V3 power-supply as the nRF)
• exactly: TWI is working fine until some disturbances happen (in this case acceleration)

the I2C sensor is an accelerometer, so the whole device will move quite significantly. the screenshot shows that the TWI connection "dies" upon a sudden movement.

it wouldn't be much of an issue to implement a recovery mechanism on a higher level (e.g., monitor the sensor to be "alive"), but i want to avoid changing the drivers since i don't want to dig in deep into the peripherals, also because i'd like to be able to switch between nRF2/nRF1 series by simply changing the SDK.

thanks!

[martin]

btw: i'm not running any BLE connection / no softdevice yet.

[endnode]

I see. Isn't it purely mechanical problem? As far as I see nRF51822 Beacon Kit doesn't have any good PIN header so i suppose you've soldered the sensor right on the PCB pins? Or are there any clumpsy wires hanging around the HW in the air? I could imagine any issue with levels on these lines because of short or dropped voltage from 3V3 pull-ups will kill current transfer.... just random ideas. To be fair I've switched to nRF52 exactly because lack of wired interfaces and weaknesses of the once which nRF51 has (I know, this is now what you want to hear, but maybe a way to save some time i your life?:)