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

[Darrel Taylor]

If you put a crystal on the Timer1 oscillator, enable T1OSCEN and change TMR1CS before going to sleep with an appropriate reload value for the lower frequency ... you could put it to sleep.

[aberco]

Hmm I don't really understand, I have this at the beginning of my code during initialization:

T1CON = %01101011 'Set Timer prescaler to /4 and enable Timer1 on external 32768Hz crystal

T1OSCEN = 1 (secondary 32768Hz oscillator is enabled)
TMR1CS = 1 (timer clock source is secondary 32768Hz oscillator)

My setup already use the Timer1 for both interrupt and general clock source when in low power mode, and it does work as expected.

I tried to add that T1CON configuration line above my @ SLEEP instruction but that didn't help much. If the SLEEP mode actually turn off all clocking sources then T1OSCEN bit should be set to 0 as well.

Maybe using the IDLE mode and manually disable all peripherals that are enabled default would be a workaround.

[Darrel Taylor]

Timer1 oscillator continues to run during sleep mode, but ... try it like this.
First, comment all the OSCCON and OSCTUNE statements you showed above.

Then ...

StandAloneLoop:
  ASM
    SLEEP
    NOP
    NOP
  ENDASM
GOTO StandAloneLoop

[aberco]

Tried this step by step.

Commenting either or all of these:

OSCCON.1 = 0
OSCCON.0 = 1 'Use Timer1 oscillator as clock source
OSCCON.7 = 1 'Device enters in IDLE mode when sleep instruction issued

stop operation. However I'm not sure if it's because the interrupt is not triggered anymore or if that's because the CPU does not come back from sleep. I remember reading that Timer1 oscillator was always running, but looking carefully at the datasheet again I cannot find that statement back. Only mention is that SLEEP (not IDLE) mode turn off all clocks and all oscillators, expect for the WDT oscillator (if enabled).

[Darrel Taylor]

And you had more statements than those 3.
One of them disables the Primary Oscillator, which will keep it from running after it wakes up I would assume.

[aberco]

Yes but I commented all others as well. I just quoted the lines that caused the interrupt to stop working.

I want to disable the primary oscillator, because I have 2 operating modes:

1) USB attached, clocked from a 12Mhz ceramic resonator, with PLL enabled and CPU clocked at 48Mhz

2) USB detached, standalone, CPU and peripherial clocked from Timer1 secondary oscillator.

When the CPU wakes from sleep it should resume on the oscillator defined by the SCS bits, here SEC_RUN mode:

OSCCON.1 = 0
OSCCON.0 = 1 'Use Timer1 oscillator as clock source

Now you found that statement back from the datasheet, there's hope to make it work! I'll investigate harder and make some tests on a simplified program.

[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?