5 Replies Latest reply on May 18, 2015 8:36 AM by merwin.rozenberg

    I2CHW - SDA line low problem - detection and solution

    merwin.rozenberg

       Hello,

         

      In one of our appllications we're using the I2CHW module (configured as "master only"). We're using it to read/write an EEprom and an I/O expander.

         

      Our problem:

         

      Sometimes, due to a power failure, the main processor resets. Sometimes after that the I/O expander or the EEprom keeps the SDA line low.

         

      Now an I2C slave is holding the SDA line low and our main processor won't startup after its reset because it couldn't finish an I2C transfer. How do you detect something like this and how do you solve this?

         

      Our solution:

         

      On a wiki page i found this:

         

      "There are a couple ways to recover from this scenario.

         

      Option 1: For devices that mux the SCL/SDA pins with GPIO, the easiest thing is to configure the pins for GPIO operation and toggle SCL until the slave releases SDA. At this point you should be able to resume normal operation.

         

       

         

      Option 2: Many devices don't mux SCL/SDA with GPIO since the I2C I/O cells are often special open drain cells. A workaround has been reported to work even on these devices. By configuring the I2C for "free data format" and then reading a byte the I2C will immediately start sending clocks to input data (rather than trying to send an address). This can be used to free up the bus."

         

      Source: http://processors.wiki.ti.com/index.php/I2C_Tips

         

      For our application option 1 could be the answer. So we've written a solution and tested in our application. For us this works right now and doesn't give any problem.

         

      You can find it in the attachment.

         

      The question are:

         

      - Do you see something what's wrong or possible go wrong while running?

         

      - Are there better solutions? Faster/cleaner code or ....

         

      Merwin

        • 1. Re: I2CHW - SDA line low problem - detection and solution
          user_14586677

          Researching the problem those methods seem pretty common.

             

           

             

          I also wonder if I2C slave's power was gated by PSOC, eg just tie its

             

          pin to a GPIO, a reset could be forced thru startup. Most I2C devices

             

          draw a low enough amount of power using this approach no significant

             

          noise margin impact would be felt.

             

           

             

          Also detection of the condition begs some timeout via use of a timer or

             

          time based condition. Or error return counting over time. I2C specification

             

          does not have a limit, like SMBuss.

             

           

             

          Regards, Dana.

          • 2. Re: I2CHW - SDA line low problem - detection and solution
            merwin.rozenberg

             Dana,

               

            The I2C slave's power is not gated by the main processor. It also is not possible to do that right now.

               

            The functions "I2CHW_1_bWriteBytes" and "I2CHW_1_fReadBytes" both do not return values where you can see if there are errors. The only function which returns some information is "I2CHW_1_bReadI2CStatus".

               

            What do you mean with: "I2C specification does not have a limit, like SMBuss."

               

            Implementing a timer in our software would mean the following thing:

               

            - Adding an extra timer. Takes some space/recources in the processor.

               

            - Adding the code to handle timer/interrupt and handle the possible error state.

               

            For now this solution works for us. If the I2C slave device still give's errors, after the processsor tried to solve the error, it would mean that there's something else wrong for instance a hardware problem. What would then be the benefit for us to add a timer and the needed software to handle the error?

               

            Another advantage of this solution is that if we need to update a software version, we replace the I2C.c source file, recompile the project and we're done.

               

            Thanks for your answer,

               

            Merwin

            • 3. Re: I2CHW - SDA line low problem - detection and solution
              user_14586677

              What do you mean with: "I2C specification does not have a limit, like SMBuss."

                 

               

                 

              From the SMBuss specs there is a limite to clcok stretch -

                 

               

                 

               

                 

               

                 

              Regards, Dana.

                 


              • 4. Re: I2CHW - SDA line low problem - detection and solution
                merwin.rozenberg

                 Dana,

                   

                 

                   

                Can you tell/explain me how this is related to the problem of a I2C slave keeping the SDA line low?

                   

                I thought that clock stretching is that the I2C slave keeps the SCL line low for a certain amount of time to reduce the bus speed.

                   

                 

                   

                Regards,

                   

                Merwin

                • 5. Re: I2CHW - SDA line low problem - detection and solution
                  user_14586677

                  My point is that I2C has no limits on clock stretch, so a timeout

                     

                  mechanism has to be provided by user. Whereas people wisened

                     

                  up and incorporated that into SMBuss.

                     

                   

                     

                  I think what you are doing, given you are HW contrained, seems

                     

                  reasonable.

                     

                   

                     

                  Regards, Dana.