unintentional I2c writes to eeprom

[PicFan]

I've encountered a problem with a 24LC256 that has me more than a bit confused. Over the past couple of months, an application that I designed has somehow managed, several times, to "write" over one or two of the 44 application setpoints with two consistent values of 161 and 255 always in pair(s) and always in that order.

In this application, I read from the eeprom heavily but intentional writes are only supposed to result from an onboard keypad to allow the user to change any of the setpoints. The keypad routines also limit the value range that a setpoint can be changed to and would not allow values of 161 or 255 to be selected to be written.

I think I may have found the source of this but I'm not comfortable that I know what to do about it.

I used the 24256.c driver file in my code and I recently noticed that the read_ext_eeprom function and write_ext_eeprom function have a striking similarity. So similar in fact, that if the restart condition (second i2c_start below) were to be skipped or somehow did not qualify, the read function would WRITE (unsigned) a 161 and 255 in two subsequent eeprom locations.

byte read_ext_eeprom(long int address) {
byte data;
i2c_start();
i2c_write(0xa0);
i2c_write(address>>8);
i2c_write(address);
i2c_start();
i2c_write(0xa1);
data=i2c_read(0);
i2c_stop();
return(data);
}


Although I have the bus connected to the 18f452 hardware i2c lines, I'm using software functionality as below:
#use i2c(master,sda=E2_SDA, scl=E2_SCL, SLOW)


I currently have two 24LC256 eeproms and a DS1307 connected to the same two i2c lines using 4.7K pullup resistors. On the scope, the rise and fall times look to be within the spec as I understand it to be for regular mode clock speed of 100kHz.

Could someone please nudge me the right direction here. I'm not sure what to do at this point and sort of desperate.

Thanks in advance for any and all suggestions!
___________________________
This message was ported from CCS's old forum
Original Post ID: 12096

[PCM programmer]

:=
:=byte read_ext_eeprom(long int address) {
:= byte data;
:= i2c_start();
:= i2c_write(0xa0);
:= i2c_write(address>>8);
:= i2c_write(address);
:= i2c_start();
:= i2c_write(0xa1);
:= data=i2c_read(0);
:= i2c_stop();
:= return(data);
:=}
:=
:=
:=I currently have two 24LC256 eeproms and a DS1307 connected to the same two i2c lines using 4.7K pullup resistors. On the scope, the rise and fall times look to be within the spec as I understand it to be for regular mode clock speed of 100kHz.
----------------------------------------------------------
1. Do you have a delay_ms() statement at the end of your
eeprom write function ? What is the delay ?

2. What is the supply voltage for the PIC, eeprom and DS1307 ?

3. As a test, try putting each device on its own separate
i2 bus.
___________________________
This message was ported from CCS's old forum
Original Post ID: 12099

[PicFan]

:=:=
:=:=byte read_ext_eeprom(long int address) {
:=:= byte data;
:=:= i2c_start();
:=:= i2c_write(0xa0);
:=:= i2c_write(address>>8);
:=:= i2c_write(address);
:=:= i2c_start();
:=:= i2c_write(0xa1);
:=:= data=i2c_read(0);
:=:= i2c_stop();
:=:= return(data);
:=:=}
:=:=
:=:=
:=:=I currently have two 24LC256 eeproms and a DS1307 connected to the same two i2c lines using 4.7K pullup resistors. On the scope, the rise and fall times look to be within the spec as I understand it to be for regular mode clock speed of 100kHz.
:=----------------------------------------------------------
:=1. Do you have a delay_ms() statement at the end of your
:= eeprom write function ? What is the delay ?
:=
:=2. What is the supply voltage for the PIC, eeprom and DS1307 ?
:=
:=3. As a test, try putting each device on its own separate
:= i2 bus.



PCM programmer,

I do have a delay_ms(11) and the end of the write_ext_eeprom function and my power supply is a firm 5.08vdc and is common for the PIC, eeproms and the DS1307.

But I don't think the write_ext_eeprom function is at fault for this since the logic of the code doesn't call it except in the case of a keypad change (which to my knowledge isn't happening) but yet two of the values (never the same two) will eventually change to a 161 and a 255. And I unfortunately can't get the problem to duplicate on the bench (even with considerable effort). It only happens on one of the controller appications (and several different controller boards on this app) and only while its in the field. Its very perplexing.

I do have the comm interrupt enabled for EIA485 communications also.

I was just thinking that if a comm interrupt (I'm not disabling ints in C code) or noise or something might in someway cause the software i2c to inappropriately represent the restart condition, that the following direction change value (read) of 0xa1 would then be written as data (since a restart did not occur) and then the i2c_read statement would clock 8 bits with the data line released which to the eeprom would look like a data write with a value of 0xff.

I'm also a little concerned with the pullup resistor values at 4.7K. Do you think it would be helpful to decrease them?

Is there a signal quality advantage to using hardware i2c?

I've spent considerable time reading the Phillips I2C specification, but I still don't know, is there a timeout inferred in the i2c if the micro were to inadvertantly stop servicing it midstream?

Also, since the problem is on a production quality board, it would be nearly impossible to separate the components onto individual busses connected to the PIC.


With Best Regards,
PicFan
___________________________
This message was ported from CCS's old forum
Original Post ID: 12102

[PCM programmer]

:=I do have the comm interrupt enabled for EIA485 communications also.
:=
:=I was just thinking that if a comm interrupt (I'm not disabling ints in C code) or noise or something might in someway cause the software i2c to inappropriately represent the restart condition, that the following direction change value (read) of 0xa1 would then be written as data (since a restart did not occur) and then the i2c_read statement would clock 8 bits with the data line released which to the eeprom would look like a data write with a value of 0xff.
:=
:=I'm also a little concerned with the pullup resistor values at 4.7K. Do you think it would be helpful to decrease them?
:=
:=Is there a signal quality advantage to using hardware i2c?
:=
:=I've spent considerable time reading the Phillips I2C specification, but I still don't know, is there a timeout inferred in the i2c if the micro were to inadvertantly stop servicing it midstream?
---------------------------------------------------------

You could reduce the resistors to 2.2K, but I doubt if
that's the problem. It's worth a try.

I tested the hardware i2c a couple years ago, and I found
the clock waveform has an inverted duty cycle, compared to
the Philips spec. I informed Microchip, but never got any
response.

This appnote says i2c has no timeout.
<a href="http://dbserv.maxim-ic.com/appnotes.cfm?appnote_number=356" TARGET="_blank">http://dbserv.maxim-ic.com/appnotes.cfm?appnote_number=356</a>

1. The next thing I would try is to enclose your low-level i2c
code with enable/disable interrupts.

2. If that doesn't work, then since you only have one i2c bus,
try removing the DS1307 and modify the code to not use it.
I'm just trying to isolate the problem.

3. Also, try a different brand of eeprom. Perhaps Atmel ?

4. What's your version of the PCH compiler ?
___________________________
This message was ported from CCS's old forum
Original Post ID: 12103

[PicFan]

:=---------------------------------------------------------
:=
:=You could reduce the resistors to 2.2K, but I doubt if
:=that's the problem. It's worth a try.
:=
:=I tested the hardware i2c a couple years ago, and I found
:=the clock waveform has an inverted duty cycle, compared to
:=the Philips spec. I informed Microchip, but never got any
:=response.
:=
:=This appnote says i2c has no timeout.
:= <a href="http://dbserv.maxim-ic.com/appnotes.cfm?appnote_number=356" TARGET="_blank"> <a href="http://dbserv.maxim-ic.com/appnotes.cfm?appnote_number=356" TARGET="_blank">http://dbserv.maxim-ic.com/appnotes.cfm?appnote_number=356</a></a>
:=
:=1. The next thing I would try is to enclose your low-level i2c
:=code with enable/disable interrupts.
:=
:=2. If that doesn't work, then since you only have one i2c bus,
:= try removing the DS1307 and modify the code to not use it.
:= I'm just trying to isolate the problem.
:=
:=3. Also, try a different brand of eeprom. Perhaps Atmel ?
:=
:=4. What's your version of the PCH compiler ?



PCM programmer,

When you mention your tests of the hardware i2c as resulting in "the clock waveform has an inverted duty cycle", I find this very interesting but sort of confusing. I guess I wasn't aware that duty cycle would be in play when using i2c. Can you give me a clarification that I can use my scope to look for and maybe confirm if that is still an issue?

And thanks for the web link in reference to the no i2c timeout. That logic was pretty obscure (non-existant in the Philips I2c spec I've been reading.

(1) If I end up using hardware i2c, do you think disabling ints would be a useful advantage? In my app, communications are a very high priority feature, so I'm a bit hesitant to disable the int and chance introducing a latency.

(2) I think the idea of narrowing the field of opportunity by removing the RTC is quite logical. I wish this problem of mine weren't so elusive. I have not been able to reproduce it on the bench and it is very sporadic and non-predictable in the field, but the controller hardware needs the real-time-clock to perform its main duties and disabling it would prevent the board from being of much use.

(3) I hadn't thought about using a different brand eeprom. Thanks for the suggestion! I'll do that as soon as I can get some ordered.

(4) I tend to stay with a version of the compiler that seems to work. Currently I have confidence in 3.130. For my use, this seems to be very stable. However, I do have a current subscription and I have archived virtually every downloadable version available. Do you have a tried and true version preference?

Thanks for sharing your knowledge! I do appreciate it!

Best Regards,
PicFan
___________________________
This message was ported from CCS's old forum
Original Post ID: 12104

[PCM programmer]

:=When you mention your tests of the hardware i2c as resulting in "the clock waveform has an inverted duty cycle", I find this very interesting but sort of confusing. I guess I wasn't aware that duty cycle would be in play when using i2c. Can you give me a clarification that I can use my scope to look for and maybe confirm if that is still an issue?
:=
Look at Table 5 in the Philips i2c spec:
<a href="http://www.semiconductors.philips.com/acrobat/various/I2C_BUS_SPECIFICATION_3.pdf" TARGET="_blank">http://www.semiconductors.philips.com/acrobat/various/I2C_BUS_SPECIFICATION_3.pdf</a>
It expects the low time of SCL to be longer than the high time.
But, a couple years ago, I did a project with a 16F876, and
the SCL signal had the high time longer than the low time.
It was an important issue for me, because I wanted to run
an FRAM memory with a SCL of 1 MHz. But I had to reduce the
frequency because at 1 MHz it violated the duty-cycle spec
for the FRAM (FM24C64 from <a href="http://www.ramtron.com" TARGET="_blank">http://www.ramtron.com</a> ).

:=(1) If I end up using hardware i2c, do you think disabling ints would be a useful advantage? In my app, communications are a very high priority feature, so I'm a bit hesitant to disable the int and chance introducing a latency.

Even with the H/W i2c, the i2c events such as Start bit, Stop
bit, Re-start, and "send data byte", are discrete events that
can't be queued (per the PIC data sheet and reference manual).
So to be sure that there is no problem, you should do a test
where you shut down interrupts during the i2c.

Try it first with H/W i2c without shutting off interrupts.
But then try it with them shut off. Your goal is to find
the source of the problem.

:=
:=(2) I think the idea of narrowing the field of opportunity by removing the RTC is quite logical. I wish this problem of mine weren't so elusive. I have not been able to reproduce it on the bench and it is very sporadic and non-predictable in the field, but the controller hardware needs the real-time-clock to perform its main duties and disabling it would prevent the board from being of much use.

Could this problem be caused by writing when the PIC is
being powered-down ? Which would cause a bad write ?

:=
:=(3) I hadn't thought about using a different brand eeprom. Thanks for the suggestion! I'll do that as soon as I can get some ordered.
:=
:=(4) I tend to stay with a version of the compiler that seems to work. Currently I have confidence in 3.130. For my use, this seems to be very stable. However, I do have a current subscription and I have archived virtually every downloadable version available. Do you have a tried and true version preference?

I don't have PCH. The people that do have it, haven't
responded yet. There may be a bug with i2c in your version,
for all I know.

Do we know for sure that your version (3.130) of PCH has the
bug fix for the 18F pre-fetch problem ? Someone who has PCH
will know.
<a href="http://www.pic-c.com/forum/general/posts/10339.html" TARGET="_blank">http://www.pic-c.com/forum/general/posts/10339.html</a>
<a href="http://www.pic-c.com/forum/general/posts/10338.html" TARGET="_blank">http://www.pic-c.com/forum/general/posts/10338.html</a>
___________________________
This message was ported from CCS's old forum
Original Post ID: 12106

[Sergio]

Do you have any more info on when the problem is occuring? How do you find out when it has occurred? Has the I2C software ever worked correctly? When did the problem start happening? Are these values 161 and 255 always random locations?

I'm just wrapping up a I2C project using a Xicor X4283 chip myself and I was surprised at all the write protection it has. That wasn't the reason I chose it but I'm glad it's there.


:=:=:=
:=:=:=byte read_ext_eeprom(long int address) {
:=:=:= byte data;
:=:=:= i2c_start();
:=:=:= i2c_write(0xa0);
:=:=:= i2c_write(address>>8);
:=:=:= i2c_write(address);
:=:=:= i2c_start();
:=:=:= i2c_write(0xa1);
:=:=:= data=i2c_read(0);
:=:=:= i2c_stop();
:=:=:= return(data);
:=:=:=}
:=:=:=
:=:=:=
:=:=:=I currently have two 24LC256 eeproms and a DS1307 connected to the same two i2c lines using 4.7K pullup resistors. On the scope, the rise and fall times look to be within the spec as I understand it to be for regular mode clock speed of 100kHz.
:=:=----------------------------------------------------------
:=:=1. Do you have a delay_ms() statement at the end of your
:=:= eeprom write function ? What is the delay ?
:=:=
:=:=2. What is the supply voltage for the PIC, eeprom and DS1307 ?
:=:=
:=:=3. As a test, try putting each device on its own separate
:=:= i2 bus.
:=
:=
:=
:=PCM programmer,
:=
:=I do have a delay_ms(11) and the end of the write_ext_eeprom function and my power supply is a firm 5.08vdc and is common for the PIC, eeproms and the DS1307.
:=
:=But I don't think the write_ext_eeprom function is at fault for this since the logic of the code doesn't call it except in the case of a keypad change (which to my knowledge isn't happening) but yet two of the values (never the same two) will eventually change to a 161 and a 255. And I unfortunately can't get the problem to duplicate on the bench (even with considerable effort). It only happens on one of the controller appications (and several different controller boards on this app) and only while its in the field. Its very perplexing.
:=
:=I do have the comm interrupt enabled for EIA485 communications also.
:=
:=I was just thinking that if a comm interrupt (I'm not disabling ints in C code) or noise or something might in someway cause the software i2c to inappropriately represent the restart condition, that the following direction change value (read) of 0xa1 would then be written as data (since a restart did not occur) and then the i2c_read statement would clock 8 bits with the data line released which to the eeprom would look like a data write with a value of 0xff.
:=
:=I'm also a little concerned with the pullup resistor values at 4.7K. Do you think it would be helpful to decrease them?
:=
:=Is there a signal quality advantage to using hardware i2c?
:=
:=I've spent considerable time reading the Phillips I2C specification, but I still don't know, is there a timeout inferred in the i2c if the micro were to inadvertantly stop servicing it midstream?
:=
:=Also, since the problem is on a production quality board, it would be nearly impossible to separate the components onto individual busses connected to the PIC.
:=
:=
:=With Best Regards,
:=PicFan
___________________________
This message was ported from CCS's old forum
Original Post ID: 12108

[Pete Smith]

:=(1) If I end up using hardware i2c, do you think disabling ints would be a useful advantage? In my app, communications are a very high priority feature, so I'm a bit hesitant to disable the int and chance introducing a latency.
:=

This has just triggered a memory with me.

I use the 1307 as a RTC (the memory's ignored). I used to run interrupts when reading from the clock.

I found that the clock would run for a minute (max), before _all_ the words in the RTC area becoming corrupted (this is while _reading_), with top-bit-set data, eg the date would become FF/FF/FF FF:FF:FF

I found that by disabling interrupts before I read the RTC, the clock would remain stable.

All I can assume is that the interrupts being on had messed up the I2C data (nothing obvious on a scope), to such an extent, that reads were being converted into writes.

I now routinely shut down interrupts while accessing any I2C device.

HTH

Pete.
___________________________
This message was ported from CCS's old forum
Original Post ID: 12112

[R.J.Hamlett]

:=I've encountered a problem with a 24LC256 that has me more than a bit confused. Over the past couple of months, an application that I designed has somehow managed, several times, to "write" over one or two of the 44 application setpoints with two consistent values of 161 and 255 always in pair(s) and always in that order.
:=
:=In this application, I read from the eeprom heavily but intentional writes are only supposed to result from an onboard keypad to allow the user to change any of the setpoints. The keypad routines also limit the value range that a setpoint can be changed to and would not allow values of 161 or 255 to be selected to be written.
:=
:=I think I may have found the source of this but I'm not comfortable that I know what to do about it.
:=
:=I used the 24256.c driver file in my code and I recently noticed that the read_ext_eeprom function and write_ext_eeprom function have a striking similarity. So similar in fact, that if the restart condition (second i2c_start below) were to be skipped or somehow did not qualify, the read function would WRITE (unsigned) a 161 and 255 in two subsequent eeprom locations.
:=
:=byte read_ext_eeprom(long int address) {
:= byte data;
:= i2c_start();
:= i2c_write(0xa0);
:= i2c_write(address>>8);
:= i2c_write(address);
:= i2c_start();
:= i2c_write(0xa1);
:= data=i2c_read(0);
:= i2c_stop();
:= return(data);
:=}
:=
:=
:=Although I have the bus connected to the 18f452 hardware i2c lines, I'm using software functionality as below:
:=#use i2c(master,sda=E2_SDA, scl=E2_SCL, SLOW)
:=
:=
:=I currently have two 24LC256 eeproms and a DS1307 connected to the same two i2c lines using 4.7K pullup resistors. On the scope, the rise and fall times look to be within the spec as I understand it to be for regular mode clock speed of 100kHz.
:=
:=Could someone please nudge me the right direction here. I'm not sure what to do at this point and sort of desperate.
:=
:=Thanks in advance for any and all suggestions!

As others have said, interrupts may be the key.
I have used this chip, for several months now in a project, where I/O has been totally reliable. However I write and read, in a synchronous manner to other events in the project. What happens for me, is that I have a master 'clock' going round the board, and when the edge of this occurs, I do the I/O to this chip, if any is waiting. Because of the way this is done, no other interrupt can occur to this chip, till this I/O is complete. I then set a line, which allows other events to occur, and the other chips synchronise to this. I suspect this is why I have not seen your problem.
I would look at disabling interrupts for the read code.

Best Wishes
___________________________
This message was ported from CCS's old forum
Original Post ID: 12113

[PicFan]

:=I've encountered a problem with a 24LC256 that has me more than a bit confused. Over the past couple of months, an application that I designed has somehow managed, several times, to "write" over one or two of the 44 application setpoints with two consistent values of 161 and 255 always in pair(s) and always in that order.
:=
:=In this application, I read from the eeprom heavily but intentional writes are only supposed to result from an onboard keypad to allow the user to change any of the setpoints. The keypad routines also limit the value range that a setpoint can be changed to and would not allow values of 161 or 255 to be selected to be written.
:=
:=I think I may have found the source of this but I'm not comfortable that I know what to do about it.
:=
:=I used the 24256.c driver file in my code and I recently noticed that the read_ext_eeprom function and write_ext_eeprom function have a striking similarity. So similar in fact, that if the restart condition (second i2c_start below) were to be skipped or somehow did not qualify, the read function would WRITE (unsigned) a 161 and 255 in two subsequent eeprom locations.
:=
:=byte read_ext_eeprom(long int address) {
:= byte data;
:= i2c_start();
:= i2c_write(0xa0);
:= i2c_write(address>>8);
:= i2c_write(address);
:= i2c_start();
:= i2c_write(0xa1);
:= data=i2c_read(0);
:= i2c_stop();
:= return(data);
:=}
:=
:=
:=Although I have the bus connected to the 18f452 hardware i2c lines, I'm using software functionality as below:
:=#use i2c(master,sda=E2_SDA, scl=E2_SCL, SLOW)
:=
:=
:=I currently have two 24LC256 eeproms and a DS1307 connected to the same two i2c lines using 4.7K pullup resistors. On the scope, the rise and fall times look to be within the spec as I understand it to be for regular mode clock speed of 100kHz.
:=
:=Could someone please nudge me the right direction here. I'm not sure what to do at this point and sort of desperate.
:=
:=Thanks in advance for any and all suggestions!




I would like to personally thank all who replied, PCM programmer-R.J.Hamlett-Sergio-Pete Smith to my plea for help. I think the solution is a combination of programming practice and concept logic from all of these generously shared tips.

I am approaching the solution in the following way:

(1) I had previously been reading (random) the eeprom setpoints individually at every single use. I will now designate some ram to the beginning of a cycle and sequentially read and assign all setpoints to ram vars in one event.

(2) I will disable interrupts during this one event per (3Sec) cycle read.

(3) Since these setpoints are critical, I will utilize the WP pin on the eeprom as added protection from a read unintentionally becoming a write.

(4) (a note to PCM programmer) The HW i2c function in my application provides a cleaner signal (rise times, duration, repeatability, etc) than software i2c. The clock duty cycle is in fact inverted, longer high than low, but the software function is also inverted. So I will use HW i2c instead of software i2c.

But I still have one important question. Since the PIC could and probably will at some point reset via WDT_or_BOR_or_for_some_unknown_cause and very possibly right in the middle of an i2c transfer, what is the surest startup logic to recover from a possible botched transfer in which a PIC reset has left the i2c in an unknown state? I currently use the init_ext_eeprom() at the beginning of main(), but that only idles the buss. And since i2c has no time-out provision, would it be wise to maybe add a STOP condition in the startup code just in case?

Again, many thanks to all who replied!

Best Regards,
PicFan
___________________________
This message was ported from CCS's old forum
Original Post ID: 12176

[PCM programmer]

:=But I still have one important question. Since the PIC could and probably will at some point reset via WDT_or_BOR_or_for_some_unknown_cause and very possibly right in the middle of an i2c transfer, what is the surest startup logic to recover from a possible botched transfer in which a PIC reset has left the i2c in an unknown state? I currently use the init_ext_eeprom() at the beginning of main(), but that only idles the buss. And since i2c has no time-out provision, would it be wise to maybe add a STOP condition in the startup code just in case?
-----------------------------------------------------------

You're asking how to do error recovery on the i2c bus.
I haven't studied this subject. I can just give you a
few links that I found. Some of these links discuss
exactly what you said -- issuing a stop condition to
reset the device. But, what if the slave is holding
holding SCL or SDA low ? That's an issue, and it's
discussed in one of the links below.


On this page, download the document called "Interrupting
a 2-wire read".
http://ramtron.com/lib/literature/appnotes/interruptingread.pdf

In this document, look in the section on "Timeout and Clock
speed". Read the 4th paragraph, where it starts with
"In the I2C bus, if the slave locks up...". Also, the next
paragraph on the SMbus is interesting.
http://www.maxim-ic.com/appnotes.cfm?appnote_number=476

This FAQ question basically re-states what we already know
from reading the above items.
http://www.esacademy.com/faq/i2c/q_and_a/faq/i2cqa6.htm

Look at item #3 in this message. Sounds sort of like
your problem. Just an interesting data point.
http://archives.andrew.net.au/lm-sensors/msg01166.html

___________________________
This message was ported from CCS's old forum
Original Post ID: 12188

Edited to correct a broken link to the Maxim appnote 476.
Edited again to fix the Ramtron link.

[PicFan]

:=:=But I still have one important question. Since the PIC could and probably will at some point reset via WDT_or_BOR_or_for_some_unknown_cause and very possibly right in the middle of an i2c transfer, what is the surest startup logic to recover from a possible botched transfer in which a PIC reset has left the i2c in an unknown state? I currently use the init_ext_eeprom() at the beginning of main(), but that only idles the buss. And since i2c has no time-out provision, would it be wise to maybe add a STOP condition in the startup code just in case?
:=-----------------------------------------------------------
:=
:=You're asking how to do error recovery on the i2c bus.
:=I haven't studied this subject. I can just give you a
:=few links that I found. Some of these links discuss
:=exactly what you said -- issuing a stop condition to
:=reset the device. But, what if the slave is holding
:=holding SCL or SDA low ? That's an issue, and it's
:=discussed in one of the links below.
:=
:=
:=On this page, download the document called "Interrupting
:=a 2-wire read".
:= <a href="http://www.ramtron.com/products/appntotes.htm" TARGET="_blank"> <a href="http://www.ramtron.com/products/appntotes.htm" TARGET="_blank">http://www.ramtron.com/products/appntotes.htm</a></a>
:=
:=In this document, look in the section on "Timeout and Clock
:=speed". Read the 4th paragraph, where it starts with
:="In the I2C bus, if the slave locks up...". Also, the next
:=paragraph on the SMbus is interesting.
:= <a href="http://dbserv.maxim-ic.com/appnotes.cfm?appnote_number=356" TARGET="_blank"> <a href="http://dbserv.maxim-ic.com/appnotes.cfm?appnote_number=356" TARGET="_blank">http://dbserv.maxim-ic.com/appnotes.cfm?appnote_number=356</a></a>
:=
:=This FAQ question basically re-states what we already know
:=from reading the above items.
:= <a href="http://www.esacademy.com/faq/i2c/q_and_a/faq/i2cqa6.htm" TARGET="_blank"> <a href="http://www.esacademy.com/faq/i2c/q_and_a/faq/i2cqa6.htm" TARGET="_blank">http://www.esacademy.com/faq/i2c/q_and_a/faq/i2cqa6.htm</a></a>
:=
:=Look at item #3 in this message. Sounds sort of like
:=your problem. Just an interesting data point.
:= <a href="http://archives.andrew.net.au/lm-sensors/msg01166.html" TARGET="_blank"> <a href="http://archives.andrew.net.au/lm-sensors/msg01166.html" TARGET="_blank">http://archives.andrew.net.au/lm-sensors/msg01166.html</a></a>
:=


PCM programmer,

Superb information! After several months of hand wringing, now I know I can 'fix' this problem!

Thank you very much for the help.

With Best Regards,
PicFan
___________________________
This message was ported from CCS's old forum
Original Post ID: 12199