SCL Stuck Low with NRF52810 SDK 15.0 on Custom Board

[F Iannce]

I've got a custom board using the NRF52810 with SDK v15.0.0.

I am using the TWIM driver (nrfx_twim.c master mode) to drive an LCD driver IC, a capacitive touch sensor IC, and a fuel gauge IC.  After connection there is no activity on I2C for the LED driver IC and the Fuel Gauge IC (I am intentionally not sending them anything so as not to confuse the issue..)

After connection, my code is just reading 300 bytes of data off of the touch sensor IC five times per second.  The SCL clock is 100 kHz and the waveform looks perfectly fine.

This works well for anywhere from 5 seconds up to 60 seconds--I can see the data being sent across the I2C bus and I am capturing this data and putting it into an array without any issues.  After a while (q.v. anywhere from 5 to 60s) the SCL line goes low at the beginning of a read, and never goes high again.  I added code that detects this condition and then disables TWIM and uses nrf_gpio_cfg_default to deassert the line.  After the nrf_gpio_cfg_default line is executed, the SCL line goes back high.  This tells me that it is the NRF52 that is pulling the SCL line low, and not one of the slave I2C devices.

I can't figure out why the TWIM is stopping.  I  get no error messages, and these are what my TWIM registers say:

TASK_STARTRX:          0

TASK_STARTTX            0

TASKS_STOP                0

TASKS_SUSPEND        0

TASKS_RESUME          0

EVENTS_STOPPED      0

EVENTS_ERROR          0

EVENTS_SUSPENDED 0

EVENTS_RESTARTED  1

EVENTS_TXSTARTED   1

EVENTS_LASTRX          0

EVENTS_LASTTX         0

SHORTS ->LASTTX_STOP         1

INTEN->STOPPED         1

INTEN->ERROR             1

ERRORSRC                    0

ENABLE                           6

PSEL->SCL                     5 (correct pin)

PSEL->SDA                     6 (correct pin)

RXD->PTR                      0x200033F8 (address of correct secondary buffer)

RXD->MAXCNT              0x12C (the 300 bytes I am reading)

RXD->AMOUNT              0x02B (I've seen various numbers here from 0x000 to 0x12C)

RXD->LIST                      0

TXD->PTR                       0x20001D88 (address of correct primary buffer)

TXD->MAXCNT               2 (register address is 2 bytes)

TXD->AMOUNT               2

TXD->LIST                       0

ADDRESS                        0x74 (correct I2C address)

Any ideas what may be happening?

[Nguyen Hoan Hoang]

I think the MAXCNT is limited to 0xFF only.  Although the datasheet showed a 32bits value.  The AMOUNT is limited to 8 bits.  The behaviour seems to be related.  try limit to 0xFF max per transfer to see what happens.

[F Iannce]

I thought for a second that this did the trick, but it appears that it was just a slightly longer delay before the TWIM driver crashed.  I limited my read to 200 bytes, and it is still getting stuck.  I'm going to see if I can find out any more clues.  Thanks.

[F Iannce]

I put a breakpoint in my TWIM handler function.  When the SCL line is getting stuck low, I am getting an NRFX_TWIM_EVT_DONE event, but the AMOUNT != MAXCNT.  I reduced the amount of data I am transferring so that MAXCNT is now only 0xAF.

I will be writing some code to reset the I2C when this error occurs (as a workaround), but I really would like a better understanding of the root cause.  Why would I be getting an NRFX_TWIM_EVT_DONE event when I have received all of the data I requested in nrfx_twim_xfer()?  It works perfectly fine sometimes for 2-300 calls, but then suddenly one call returns done without completing the request...

[Nguyen Hoan Hoang]

Not sure what caused it but you may want to have a look at this alternative i2c driver for the nRF52.  It is probably simpler to understand. 

[F Iannce]

Thanks for the code--I'll definitely take a look a closer look at it in the near future to see if it fixes the issue.  I wish that I had the time to look into this more, but I have to get some other features working before our software team starts to complain about not having hardware to develop on and/or our delaying production schedule.

For now, I added a check in my EVT handler for the stuck condition and am performing an I2C reset, and then resending the last command.  This is a clunky "solution", but it is working.