TWI SHORTS not working

[Nick]

Device: nRF51822 Rev G0

SDK: v5.2.0

Code: raw.githubusercontent.com/.../twi_hw_master.c

Basically, the TWI driver which uses PPI channels (sd_ppi_*) works perfectly - however, the driver which utilises the newly fixed (in Rev G0 devices) shortcuts DOES NOT.

I've narrowed down the issue to TWI read transactions only (writes seem to work fine) - see attached screenshot.

Has this new code been tested by Nordic with READ transactions? I only ask as the supplied example (github.com/.../twi-display-5.1.0) only seems to issues writes to the LCD device.

Many thanks.

[RK]

I'll ask the stupid question here, having stung myself by this before. You've looked at the chip on the board you're using and checked the marking carefully with a magnifying glass (or someone with younger eyes than I have) and confirmed absolutely that it's a rev G chip.

It's hard to believe the shorts don't work after there was a PAN which supposedly fixed them.

I've been writing my own TWI interrupt-driven driver but I havent' gotten there yet, I will be most peeved if it fails.

One thing I notice on the Nordic fixed-to-use-shorts code is it enables shorts, but never disables them. Nowhere in the documentation does it say enabling one of BB_STOP and BB_SUSPEND disables the other, is it possible both are active at the same time (with unpredictable results)?

Your code uses one channel which it switches from one mode to another, so definitely doesn't have that issue.

[Nick]

Definitely a Rev G device. Chip marking: N51822 QFAAG0 1351AH

[Nick]

Your comment about disabling SHORTS pointed me in the right direction! Thank you.

Shortcuts must be disabled before the twi_master_read() function returns.

Therefore, adding "NRF_TWI1->SHORTS = 0;" right before the function returns true fixes the issue completely!

[Clem Taylor]

I wrote a interrupt driven TWI driver without PPI using SHORTS_BB_STOP and SHORTS_BB_SUSPEND and it seemed to work with my QFAAG0 (eval board or mbed board).

I did my initial testing with a LIS302DL and ran the driver for several days without problems.

However when I switched to the Invensense MPU-6500, I have been having nothing but problems with hung transactions. I don't believe I'm seeing data integrity problems, I've been reading out the firmware and computing a CRC and for non-hung transactions I haven't seen bad data.

It will run for some variable number of transactions and then get this series of long clocks and then no interrupt. LED0 is set while a I2C transaction is pending and LED1 is set around the TWI interrupt.

Here is a working transaction:

One common thing is that failure seems to be proceeded by a strange start condition, a normal start looks something like this:

But when it is going to fail I get this strange runt clock cycle:

This seems to be the case in the handful of failures I've captured, but it the failure comes several bytes later.