UART rx during sleep mode problem

[ktallevi]

I am attempting to capture a single character from a serial device while the PIC18LF8722 is in sleep mode. Everything works fine if I sit in 'idle' mode, but that consumes too much power. I am using a 10Mhz crystal as my main running clock, although I shut that down while in sleep using setup_oscillator(OSC_31250); The circuit draws 60uA in sleep mode, which I am happy with.

I have wired the receive pin to both UART1 and EXT1. my idea is that the high-to-low transition will trigger EXT1 and wake up the PIC, the first instruction will be a getc() ... or a timed getc routine.

So far my logic is correct, but the character is not being read properly, I keep getting 255 back. The character I'm expecting is 165. Again, the problem only occurs in sleep mode, not idle mode.

My assumption is that upon EXT1 being triggered, the PIC switches from 31khz to the 10mhz external crystal. The delay period of the PIC waking up and the 10mhz crystal stabilizing is too long for the character to be properly read.

Without pasting the entire code , which is not really necessary, here are the relevant portions...

[ckielstra]

[ktallevi]

So any ideas as to capturing the character upon waking up? The character is being received at 9600bps, so I would need to power up before the start of the first data bit (100usec or so). Is there a way to keep that single hardware UART active while the device is in sleep mode, without using idle mode of course.

I'm open to any other ideas of course.

thanks

[Ttelmah]

The problem is that the UART, is clocked by the processor clock, and cannot work without a clock.
What you can do, is have the command to switch the clock to a slow rate (but still running), and then a new #use delay statement, and #use RS232 statement, for this clock rate. Then the UART is running and clocked at the slower rate, to receive the first character.
Unfortunately though, the 32K clock, is not fast enough to operate the UART for 9600bps reception. The UART will trigger a 'wake' on the first edge of the start bit, but cannot then clock the data in, till the main oscillator has woken.
The normal way to deal with this, is to send a dummy 'wake up' character, in front of the actua data, with enough delay, for the oscillator to have started, before the main data is sent.
Unfortunately, this is hardware limitation.

Best Wishes

[SherpaDoug]

Why are you sleeping at 32kHz? If it is just something readily available and slow enough to save power without being stopped, but accuracy is not too important, you might try a faster sleep clock, like a 200kHz resonator. It might be slow enough to save power, but fast enough to run your UART.
_________________
The search for better is endless. Instead simply find very good and get the job done.

[Neutone]

I think it's worth mentioning that a crystal speed of 38400 will allow you to run in low power mode and still receive at 9600 baud with no error using only the low speed crystal. It will use about the same power that a clock crystal would use but operating a real time clock becomes more complicated. Also, you may be able to go much lower than 60uA in low power mode.

[ktallevi]

so the best course of action should be enable sleep mode, but use a faster crystal. I'll have to calculate the lowest possible crystal value that allows for 9600 reception, but still provides good power saving.

[Neutone]

[ktallevi]

I still need the 10Mhz crystal for other purposes, so could I put the 38.4khz crystal on RC0/RC1 and use setup_oscillator(OSC_TIMER1)?

This way the PIC could run off the 38.4khz until it gets the data from the 9600 bps device (instead of sleeping), read the data, then switch back to the 10Mhz crystal again for full operation.

thanks