My company had I2C lockups in one of our products. The issue was a watchdog reset was occurring in the middle of a I2C transition in which the I2C device had control of the bus. When the unit restarted the entire bus was unresponsive. Our solution was to do what others are suggesting and clock the bus up to 9 times while looking for the SDA pin to return high.

In my opinion this problem is one of the main reasons why I try and avoid I2C in designs. I prefer to use SPI devices since they can be easily reset by de-asserting the chip select pin.

--- In m..., Matthias Weingart wrote:
>
> Have you checked the errata-sheet of your controller? The I2C had many bugs -
> I changed to my own bit banging routines after a similar nightmare. (btw. the
> code of the software-I2C was smaller than the code using the I2C hardware
> ;-).
>
> M.
>
> "merapcb" :
>
> >
> > Hi Stuart and thank you. Yes, it is "painful" (actually without the
> > quotes), especially when an advanced proto is in the field and this
> > crops up. 99% is not 100%.
> >
> > As for a solution, the first thing I will try, as a work around, is to
> > implement a timer in the while statement for reading the byte and if the
> > bus hangs, that will get me out of there. But then the real issue
> > starts, which is to recover the state of the application (data pointers
> > etc) and since this function is called almost in 100 places in the
> > application, I suspect much pain....
> >
> >
> > --- In m..., "Stuart_Rubin" wrote:
> >>
> >> merapcb, I feel your pain!
> >>
> >> In my experience, the upfront cost of making the robust software is
> >> worthwhile. If your hang-ups are occurring say once an hour, this is a
> >> problem. If you were to implement noise suppression, extra clocks,
> >> whatever..., you might get the hang-up once a week. That's a bigger
> >> problem! You'll have customer complaints, but can't reproduce them.
> >>
> >> So, I think adding some software robustness to your code may be
> >> worthwhile. I suspect it's not quite as bad as it seems. Also in my
> >> experience, when adding more robust software and debugging it, I have
> >> stumbled on the root cause of the problem.
> >>
> >> Good luck. Please report back your solution.
> >>
> >> Stuart
>

Start a New Thread

Just a small update. Firstly, I have read a lot and seem to get the pictures that I2C is or can be problematic (in general) and that SPI is preferred. Well, chalk it up for next design...

Anyway, while implementing a software safeguard, I also feel it may very well be noise induced (don't know why, other than the fact that it happens in the field and not in lab). My present board is a dual layer board and I am not an expert on layout (someone else does it) but I gather some precautions could be taken. For example:
a) should the I2C traces be as short as possible?
b) should they be "enclosed/surrounded" by ground plane?
c) I have seen series resistors used, is that a good idea?

I have placed two images of the current PCB here:
http://tech.groups.yahoo.com/group/msp430/files/Uploads/I2C%20issue/

Thanks

Start a New Thread

To add to my previous post, I have also uploaded my entire I2C driver code here...

http://f1.grp.yahoofs.com/v1/YH-zTojdeE3Kq6QYsPdrcGtx9WNKxG2NUKmiGbVjxw-SDdrnna40LAz9NASbkmRFhx9LOUCMaXIdmYe9UInwZeFgSrKs/Uploads/I2C%20issue/I2C_Driver.txt

Please note that I am using both I2C and UART on the same USART0 (but not at the same time). When tha application wants to use a peripheral (EEPROM/RTC) it calls I2C_Init() and when it is finished it calls I2C_Exit() which restores the USART to UART mode.

--- In m..., "merapcb" wrote:

>
> I have placed two images of the current PCB here:
> http://tech.groups.yahoo.com/group/msp430/files/Uploads/I2C%20issue/
>
> Thanks
>

Start a New Thread

"merapcb" :

> I have placed two images of the current PCB here:
> http://tech.groups.yahoo.com/group/msp430/files/Uploads/I2C%20issue/
>

Please post the circuit diagram. How big are the pull-ups?

M.

Start a New Thread

The pull-ups are 4.7K (R28, R29)

I have posted the circuit also:
http://tech.groups.yahoo.com/group/msp430/files/Uploads/I2C%20issue/
--- In m..., Matthias Weingart wrote:
>
> "merapcb" :
> Please post the circuit diagram. How big are the pull-ups?
>
> M.
>

Start a New Thread

In general, lower pull-up resistor values will get you less noise, but higher power consumption. 4K7 doesn't sound too low, though, but it's something to think about.

Stuart

--- In m..., "merapcb" wrote:
> The pull-ups are 4.7K (R28, R29)
>
> I have posted the circuit also:
> http://tech.groups.yahoo.com/group/msp430/files/Uploads/I2C%20issue/
> --- In m..., Matthias Weingart wrote:
> >
> > "merapcb" :
> >
> >
> > Please post the circuit diagram. How big are the pull-ups?
> >
> > M.
>

Start a New Thread

So you are suggesting that if my application does not care about power (i.e. not battery operated etc) then I lower it? To how much? 2K? 1K?
--- In m..., "Stuart_Rubin" wrote:
>
> In general, lower pull-up resistor values will get you less noise, but higher power consumption. 4K7 doesn't sound too low, though, but it's something to think about.
>
> Stuart
>

Start a New Thread

merapcb wrote:
> Just a small update. Firstly, I have read a lot and seem to get the pictures that I2C is or can be problematic (in general) and that SPI is preferred. Well, chalk it up for next design...
>
> Anyway, while implementing a software safeguard, I also feel it may very well be noise induced (don't know why, other than the fact that it happens in the field and not in lab). My present board is a dual layer board and I am not an expert on layout (someone else does it) but I gather some precautions could be taken. For example:
> a) should the I2C traces be as short as possible?
Yes.
> b) should they be "enclosed/surrounded" by ground plane?
On a two-layer board, yes.
> c) I have seen series resistors used, is that a good idea?
>

I don't see a use in that unless you have long lines and for some
reasons (such as power consumption) you can't place low resistance pull-ups.
> I have placed two images of the current PCB here:
> http://tech.groups.yahoo.com/group/msp430/files/Uploads/I2C%20issue/
>

The ground side of C26 goes to a long trace. That isn't a good thing, it
should run straight over to pin 4 of U8. Shoot a trace on the "green
layer" straight across. It's a clear shot, no obstacles in the way.

Same goes for C27 which should be moved north a bit and then provide a
straight path to pin 7. That can even be done on the "blue layer". Fill
out the ground a bit.

Looks like the battery connection to the RTC isn't locally bypassed. Not
sure if required but if the battery hangs off of wires I'd consider it.

Looks like the problem is not an EEPROM like you said in the first post
but with thre realtime clock?

--
Regards, Joerg

http://www.analogconsultants.com/

Start a New Thread

--- In m..., Joerg wrote:
>
> Looks like the battery connection to the RTC isn't locally bypassed. Not
> sure if required but if the battery hangs off of wires I'd consider it.

Locally bypassed? Meaning? The battery is on a holder on the PCB.
> Looks like the problem is not an EEPROM like you said in the first post
> but with thre realtime clock?
>

Why do you say that? Actually, it is true that I don't know if it is with RTC or EEPROM (or both). I assumed EEPROM but it may be RTC. I was not fortunate enough to capture that data on debugger (yet).

Start a New Thread

Locally bypassed means to have bypass capacitors near the power pins of the RTC (like you should have near all digital chips).

Emmett Redd, Ph.D., Professor mailto:E...@MissouriState.Edu
Physics, Astronomy, and Materials Science Office: 417-836-5221
Missouri State University Dept: 417-838-5131
901 S NATIONAL AVENUE FAX: 417-836-6226
SPRINGFIELD, MO 65897 USA Lab: 417-836-3770

It is clear that thought is not free if the profession of certain opinions make it impossible to earn a living. -- Bertrand Russel

> -----Original Message-----
> From: m... [mailto:m...] On Behalf
> Of merapcb
> Sent: Friday, November 04, 2011 2:04 PM
> To: m...
> Subject: [msp430] Re: I2C hanging
>
> --- In m..., Joerg wrote:
> >
> > Looks like the battery connection to the RTC isn't locally bypassed.
> > Not sure if required but if the battery hangs off of wires I'd
> consider it.
>
> Locally bypassed? Meaning? The battery is on a holder on the PCB.
> > Looks like the problem is not an EEPROM like you said in the first
> > post but with thre realtime clock?
> > Why do you say that? Actually, it is true that I don't know if it is
> with RTC or EEPROM (or both). I assumed EEPROM but it may be RTC. I was
> not fortunate enough to capture that data on debugger (yet).
>
> Start a New Thread