PIC18F13K50, CDC USB communication and ultra-low power temperature logger

[aberco]

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:

DataValue = TempH >> 4

modify the original value of TempH?

[aberco]

The logger project is getting near completion! I am now into the autonomous mode power, and I was able to measure these figures while powering the device from a battery across a 10 ohm shunt.



It is quite clear that I have to improve power consumption as at 900µA the 130mAh battery runs for about 6 days... The PIC sits most of the time at IDLE, and here it shows where a second sample is read and written to memory with the first previously read sample (hence the 3 write cycles for 2x 12bits).

I have not managed yet to make the true sleep mode to work, but at IDLE the power consumption seems to be very high... there's no difference than when running the CPU from internal clock at 250kHz. As I said above I tried running the CPU from Timer1 oscillator but that gave me some memory writing issue so I quitted.

Other than the PIC eating power I have (when IDLE):
LDO regulator, 500nA
I2C EEPROM, 1µA
I2C Temperature sensor, 1µA
220k/220k voltage divider, 5µA

Will try to investigate more and post results

[Ioannis]

Maybe you can control EEPROM and Temp. Sensor power by a pin from your controller. When you have to make new measurements, just make the pin high, wait a little to let the circuit settle, and do your sampling and writing. Then switch them off again.

Ioannis

[aberco]

Design is completed and can't be changed, beside there's no available I/O pin left.

IDLE power consumption is actually from the PIC and not from the peripherals.

[pedja089]

I managed to reduce consumption to less than 50uA.
Here is main part of the code.

[aberco]

That would be pretty good! I will have a look at how you managed to get that and will let you know. Thanks for the help!

[aberco]

Took me too long to edit the previous post, I got locked!

I have downloaded the XLP LowPower App note from microchip and it is helpful. The 14K50 does not allows for deep sleep, but regular sleep should do.

Obviously IDLE mode consumes 25% less than the normal run power, so I will have to make the Sleep mode to work while getting the PIC to resume from it. However there's probably something else that I have to find out, as 900µA seems to be abnormal for IDLE at 250kHz... I'll have to double check if the peripherals are also turning into low power too. I have also reduced the power supply to 2.2V (the regulator is able to switch from 3.3V for USB operation to 2.2V - TPS780330220 from TI). that should help a bit with consumption.

Could the I2C pullup be a problem? I have used 6.8k resistors which is pretty much the maximum, at 10k and beyond the operation of the I2C bus is unstable.