I realized that I have a very strange problem when I write to my I2C EEPROM when the CPU is clocked at 32.768kHz, I get corrupted data if there's a long chain of "0" being sent.

I record my temperature samples two by two, and they span 3 bytes in memory (Byte A, B and C). One sample is 12bit, 8 bit for integer value (Sign + 7 bit value), and 4 bits for decimal value (0.0625 steps). They are recoded with an interleave routine as such:

Sample 1 : AAAAAAAA.BBBB
Sample 2 : BBBBCCCC.CCCC

1811 2010/10/29 0h44m00s +23.9375
1812 2010/10/29 0h44m10s +23.9375

1813 2010/10/29 0h44m20s +24.0000
1814 2010/10/29 0h44m30s -7.9375

1815 2010/10/29 0h44m40s +24.0000
1816 2010/10/29 0h44m50s -7.9375

1817 2010/10/29 0h45m00s +24.0000
1818 2010/10/29 0h45m10s -8.0000

1819 2010/10/29 0h45m20s +23.9375
1820 2010/10/29 0h45m30s +23.9375
I have a 5ms pause between the 3 write operations, and there's about 20 sec between the record of each packets of 3 bytes. I tried increasing the write delay to 20ms without changes, and EEPROM VCC is within range.

This occurs when odd samples ends with .0000, .2500, .5000, and .7500, the problem does not appears if I run the CPU using the internal oscillator at 250kHz (and readjusting all the delay values accordingly), which makes me wonder if I2CWRITE can be used with a CPU clock of 32.768kHz...

Also, this might be related to the issue I have... is doing such operation:
Code:
DataValue = TempH >> 4
modify the original value of TempH?