• State Verified Answer
  • Replies 8 replies
  • Subscribers 62 subscribers
  • Views 4562 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 123978
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

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.

Parents
  • 0
    • 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!

Reply
  • 0
    • 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!

Children
No Data
Related