I2CHW - SDA line low problem - detection and solution

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

cross mob
lock attach
Attachments are accessible only for community members.
Anonymous
Not applicable

 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

0 Likes
1 Solution
ETRO_SSN583
Level 9
Level 9
250 likes received 100 sign-ins 5 likes given

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.

View solution in original post

0 Likes
5 Replies
ETRO_SSN583
Level 9
Level 9
250 likes received 100 sign-ins 5 likes given

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.

0 Likes
Anonymous
Not applicable

 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

0 Likes
ETRO_SSN583
Level 9
Level 9
250 likes received 100 sign-ins 5 likes given

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.

   


0 Likes
Anonymous
Not applicable

 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

0 Likes
ETRO_SSN583
Level 9
Level 9
250 likes received 100 sign-ins 5 likes given

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.

0 Likes