[OT]i2c bus issues

cian · Guest

I'm having some trouble with an i2c MAX7314 LED driver. Basically I can i2c_write to it for a while (several seconds of continus writes) but it always locks up eventually. I have a working i2c FRAM module on the bus too though and it works no problems. The sporadic nature of the problem makes me think it's an issue with the bus and that the MAX7314 is just more sensitive than the FRAM.
I'm using a pic16lf876a at 3.3V, and hardware i2c to do 400kbit/s mode. This might be part of it actually, the FRAM module is capable of <= 400kbp/s, but the MAX7314 is only spec'd for ==400kbp/s, maybe I need to look at bus speed issues?
Has anyone come across something like this before, any suggestions welcome!
Cian

Ttelmah · Guest

Guest · Posted: Thu Jul 29, 2004 11:54 am

OK, looks like a hardware i2c issue. When I ommit the force_hw option from #use_i2c everything works fine. With force_hw though it always hangs both at 100kb/s and 400kb/s. I'm using the built-in i2c routines.

Just for completion, Vcc is 3.3V, clock is 10MHz, pull up resistors are 2.2Kohm, bus is about 10cm long (but on a prototyping board so lots of stray capacitance lying around), pull-ups are near the SCL/SDA pins on the pic. The FRAM is before the MAX7314 on the bus.

I'll try your suggestions but it seems curious that hardware i2c fails at rates that software works at.

Cian

SherpaDoug · Joined: 07 Sep 2003 Posts: 1640 Location: Cape Cod Mass USA

Are you sure the SW I2C is running at the same speed as the HW I2C? I allways though the software was a lot slower.
_________________
The search for better is endless. Instead simply find very good and get the job done.

valemike · Guest

Regarding the hardware i2c...

Dig thru Microchip's errata notices.

If I remember correctly, I once read an errata warning us not to let the i2c module idle for a long time without issuing a STOP. Are you issuing START, but not STOP, and letting it just sit there doing nothing?

-Mike

cian · Guest

OK, found the relevant section in the errata:

"In its current implementation, the module may fail to correctly recognize certain Repeated START conditions. For this discussion, a Repeated START is defined as a START condition presented to the bus after an initial valid START condition has been recognized and the START status bit (SSPSTAT<3>) has been set, and before a valid STOP condition is received. If a Repeated START is not recognized, a loss of synchronization between the Master and Slave may occur; the condition may continue until the module is reset. A NACK condition, generated by the Slave for any reason, will not reset the module."

I think noise on the line is causing one of these repeat start conditions and the hardware i2c module is freezing up because of it. This SHOULD go away when I build this circuit properly on a PCB, but software i2c works fine anyway so I might just stick with that.

Cheers,
Cian

Ttelmah · Guest