• State Verified Answer
  • Locked Locked
  • Replies 9 replies
  • Subscribers 67 subscribers
  • Views 6902 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 102915
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

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.

image description

Parents
  • 0

    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.

    image description

    Here is a working transaction:

    image description

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

    image description

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

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

Reply
  • 0

    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.

    image description

    Here is a working transaction:

    image description

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

    image description

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

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

Children
No Data
Related