I2C Master stuck - MCSR stuck with START_GEN set

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Anonymous
Not applicable

In my CY8C5888FNI design with fixed-function master I2C interface (IP version 3.5), I see that very infrequently (on the order of once per hour under once-per-second accesses), the interface gets stuck after the SendStart() API function is called. Before calling SendStart(), I check the MCSR to make sure it is 0, which it is. Normally, after that call, the MCSR goes to 0x0C (BUS_BUSY and MSTR_MODE). However, in the stuck case, I see it set to 0x01 (START_GEN) - which is the bit that the call asserts. No amount of waiting helps - the register stays at 0x1.  SendStart() completes without error (NO_ERROR), but subsequent calls to I2C API functions fail with NOT_READY.

I.e., it appears that in the failing scenario, I2C interface starts out as idle, SendStart seemingly completes OK (its wait for CSR WAIT_BYTE_COMPLETE succeeds), yet the MCSR gets stuck in START_GEN and never completes.

This is quite an urgent matter, please help.

---

BTW, separately I've also observed that after calling SendStop() API, MCSR infrequently stays at 0xC for some time - however this is a transient condition, where it eventually changes to 0x0. Still, seems like this an incorrect API implementation - I'd expect SendStop() to spin until the interface and the bus go idle.

0 Likes
1 Solution
Anonymous
Not applicable

Looks like the problem was resolved by terminating a previous read with a NAK rather than an ACK. The problem was much more pronounced at 4 MHz and therefore easier to debug.

The whole sequence of the single logical operation is:

a. SendStart()

b. WriteByte()

c. Stop()

d. SendStart()

e. ReadByte()

f.  Stop()

Then the sequence repeats itself a few times a second. So the questions are:

1. When does not terminating e) with a NAK cause a silent problem in a) which subsequently breaks b) and all future operations of the interface

2. Whey does it happen only rarely at lower speeds (<=400 KHz)?

View solution in original post

0 Likes
2 Replies
Anonymous
Not applicable

BTW, this was with 100Kbps module. I tried reducing frequency to 10 Kbps, and observed another infrequent but persistent failure mode - this time it happens after the SendStop() and MCSR ends up being stuck at 0x1c, instead of going to 0x0.

0 Likes
Anonymous
Not applicable

Looks like the problem was resolved by terminating a previous read with a NAK rather than an ACK. The problem was much more pronounced at 4 MHz and therefore easier to debug.

The whole sequence of the single logical operation is:

a. SendStart()

b. WriteByte()

c. Stop()

d. SendStart()

e. ReadByte()

f.  Stop()

Then the sequence repeats itself a few times a second. So the questions are:

1. When does not terminating e) with a NAK cause a silent problem in a) which subsequently breaks b) and all future operations of the interface

2. Whey does it happen only rarely at lower speeds (<=400 KHz)?

0 Likes