TWI locks on nRF51822 v3

RE: TWI locks on nRF51822 v3

martin — Thu, 03 Aug 2017 07:54:59 GMT

hello - yeah that's just it. i switched to app_twi and use it to implement a more robust communication with the I2C transactions going on in the background. should have done so in the first place i guess ;) otherwise the issue was really a mechanical one, guess it's not a good idea to have I2C or SPI on thin wires .. thanks !

RE: TWI locks on nRF51822 v3

Hung Bui — Wed, 02 Aug 2017 11:32:46 GMT

Hi Martin,

The potential dead lock is SDK v13.x where we introduced an timeout in the while loop. Please have a look at the implementation in SDK v13.x:

  hw_timeout = HW_TIMEOUT; //10000
 while ((hw_timeout > 0) && twi_transfer(p_twi,   &p_cb->error, &p_cb->bytes_transferred,   (uint8_t *)p_data, length,  no_stop))
        {
            hw_timeout--;
        }

RE: TWI locks on nRF51822 v3

martin — Tue, 01 Aug 2017 14:28:20 GMT

that's exactly what's happening here. essentially the same thing happens on both the nRF52 and the nRF51 > except that i had to solder mini-wires to the beacon kit (the pads are extremely small). it only happens more often on the beacon due to the fact that only a little move in the wires will kill the transfer. on the nRF52 i essentially have to short them for the driver to fail.

my question here is: does the peripheral give up here or is it just the blocking-wait in the driver?

if its the latter - can i circumvent this by using the non-blocking version or are both using the same while-loop? if the non-blocking doesn't have this problem i can simply time-out the transfers and essentially implement some fault tolerance here.

there's no way i get an approval for a prototype-PCB, so i'll have to live with dangling wires.

RE: TWI locks on nRF51822 v3

endnode — Tue, 01 Aug 2017 14:15:47 GMT

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?:)

RE: TWI locks on nRF51822 v3

martin — Tue, 01 Aug 2017 14:07:43 GMT

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

RE: TWI locks on nRF51822 v3

martin — Tue, 01 Aug 2017 14:03:30 GMT

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!

RE: TWI locks on nRF51822 v3

endnode — Tue, 01 Aug 2017 13:36:03 GMT

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...

RE: TWI locks on nRF51822 v3

martin — Tue, 01 Aug 2017 13:24:14 GMT

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