- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Solved! Go to Solution.
- Labels:
-
PSoC 1
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.