![](templates/subSilver/images/CCSLogo.jpg) |
![CCS C Software and Maintenance Offers](templates/subSilver/images/forumAd6.jpg) |
View previous topic :: View next topic |
Author |
Message |
cian Guest
|
[OT]i2c bus issues |
Posted: Thu Jul 29, 2004 9:25 am |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah Guest
|
Re: [OT]i2c bus issues |
Posted: Thu Jul 29, 2004 10:57 am |
|
|
cian wrote: | 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 |
What pull up resistors are you using?. How long is the bus?. Where are the pull-ups placed?. What is the order of the IC's.
At the faster I2C rates, you have to be very careful to get the rising edges quick. You can also suffer probems from signal reflections on open wire/track ends (placing the pullups at the opposite end of the bus to the driver IC can help). If the problem IC is further along the bus, it may be that the bus capacitance is having a noticeable effect on the signals.
Best Wishes |
|
![](templates/subSilver/images/spacer.gif) |
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 |
|
![](templates/subSilver/images/spacer.gif) |
SherpaDoug
Joined: 07 Sep 2003 Posts: 1640 Location: Cape Cod Mass USA
|
|
Posted: Thu Jul 29, 2004 1:09 pm |
|
|
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. |
|
![](templates/subSilver/images/spacer.gif) |
valemike Guest
|
|
Posted: Thu Jul 29, 2004 1:25 pm |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
cian Guest
|
|
Posted: Fri Jul 30, 2004 3:20 am |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah Guest
|
|
Posted: Fri Jul 30, 2004 5:21 am |
|
|
cian wrote: | 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 |
The hardware does use a lot less processor time. Consider coding a 'timeout' recovery round the hardware code. If (for instance), you have a timer interrupt allready running, set a counter, when you start to talk to the I2C, and clear it when the communication is complete. Have the timer decrement the counter if it is not zero, and if it becomes zero (which will mean that 'count' calls to the timer have occured without the counter being cleared or reset), then reset the I2C hardware.
Best Wishes |
|
![](templates/subSilver/images/spacer.gif) |
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|