2 Replies Latest reply on Mar 2, 2018 8:33 AM by maad_2340186

    I2C Master stuck - MCSR stuck with START_GEN set

    maad_2340186

      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.

        • 1. Re: I2C Master stuck - MCSR stuck with START_GEN set
          maad_2340186

          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.

          • 2. Re: I2C Master stuck - MCSR stuck with START_GEN set
            maad_2340186

            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)?