Wake on CAN Problem.... doesn't ever wake.

[iso9001]

Hi,

Using a pic 18F4680 with ECAN I've gotten the pic to goto sleep when the can messages stop from my other node but haven't figured out whats wrong with my wake procedure, just know it never wakes up.

At the sleep routine

[Guest]

have you used setup_oscillator() to let the clock active during sleep?

[iso9001]

Never seen setup_osc()

Seems to me that it would wake without a clock since thats the default state when you goto sleep.

I'll go try it out,

I see what your thinking is that it wake on actual CAN activity and not just a change on the line. My goal is to cut my entire board down to 1mA and thats counting the LDO regulator I have... I hope thats not it since I think the clock waste a fair amount of power no ?

Wait, what is it SETUP_OSCILLATOR() is going to do ? I'm in 4xPLL w/ a 10Mhz clock, what should I be doing with this command and why is it going to keep the clock alive during a nap ?

[Guest]

well.. i had a problem with a modbus lib.. it transmitted a command and put the pic to sleep waiting for the answer... the serial interrupt should awake the pic... but it didn�t worked, because the startup time of the cristal was so long that it misses the first byte. So i had to use
setup_oscillator(OSC_IDLE_MODE)... here�s the code to give you an idea:

[Ttelmah]

A full 'sleep', can only wake up, from a 'static' peripheral trigger (external interrupt, WDT, or reset). When the chip is asleep like this, all peripherals that need a clock, are also stopped, and cannot wake the chip.
Then you have the 'idle' modes. In these, there is still a clock source, so the peripherals keep running, and can wake the chip. This is what is being selected using the setup_oscillator configuration. The 'sleep' following this, stops the core processor, but leaves the master clock running. It was not the startup time of the oscillator that mattered here, but the fact that an oscillator was still running.
Seperately, there is the issue of oscillator startup time. On most of these chips, you can also select to switch the oscillator to a low speed (and low power therefore) oscillator. If the 'main' oscillator is a normal crystal oscillator, then starting it, and getting it stable, will take significant time. You could though use this configuration, with a serial message, where the first 'wake' byte, was something like 0x00, followed by a pause, and treated as garbage. The chip will 'see' the falling edge for the start bit, and clocking at the wrong rate, latch the byte (and probably some of the subsequent 'idle high' time on the incoming line). The system wakes, and once the master oscillator is stable, can switch back to the full speed oscillator, throw away the garbage first character, and then accept the rest of the message.
So, you cannot put a device to 'sleep', and wake it with a clocked peripheral (like the serial, or CanBus module), but you can put the processor into one of the 'idle' states, with the one using the full speed 'master' oscillator, giving the least power saving, but the fastest 'wakeup'.

Best Wishes

[iso9001]

Thanks guys,

It would have been awhile before I found the answer to that!

The first can message is not of dire importance to me anyway so I'm not concerned with losing it. So you recommend I do somhing like this ?

[PCM programmer]

[iso9001]

I'll try throwing it into disabled. I thought I read that it said "its recommened to put the module into disabled" to save more power.

I'll give both a try. Its just that its raining and my laptop is in the car all the way at the end of the drive way.... with my umbrella.

Anyone have a schematic for an ultra-ionizing rain deflector or somthing ?

I just read that link PCM posted. Its a little different then the datasheet for my part but I'll try it and see what happens

[iso9001]

Interestingly Enough.... It works now, but only sort of.

It took a bit to figure out what the heck was going on because when I had the debugger active and watched the monitor it worked fine. As soon as I made a nondebug version it stopped waking up.

I narrowed it down to the #Use RS232 statement. When in debug mode I had it on, and for the normal flash I commented it out.

So.... I figure that when in debug mode the compiler does not stop the clock when sleep() is called.

To workaround I used the setup_osc command.

Which is odd b/c I agree w/ PCM that the datasheet say I can shut the clock down. Problem is that when I do it stops waking up.

Any ideas here ?

[Ttelmah]

Yes. The same is true of the latter EUARTs, but with the caveats about the oscillator wake up time, and possible garbage for the first character. On the UART, the 'edge' of the start bit is treated as if it was an interrupt,and handled statically to wake the chip. The 'core' CAN module itself can't wake you (the protocol engine, and shift registers), but there is a similar static interrupt triggered on the edge of an incoming message, which can be used to wake the system. If you actually want to receive the message that wakes you, then the oscillator has to be running.

Best Wishes

[iso9001]

So..... wait a sec.

Whats my problem here ? Is there a way to configure the INT_CANWAKE as an edge interupt (I can't tie my bus line to the B0 or B1 pins) ?

I don't understand, the datasheet shows no osc running but mine never wakes up if I don't put the chip in idle mode.... It would be best for me to turn the osc off, from a power savings standpoint.

The only thing I can think of is that datasheet posted on the CAN module doesn't say ECAN on it. Maybe they took the wake-on-can-without-osc mode out ????

[Ttelmah]

Certainly on the USART, only the 'EUSART' modules can do this. I'd expect the same to be true of the CAN modules.....
If you turn off the other peripherals youself (stop the ADC, stop the UART etc.), and put the chip into 'idle' mode, the total consumption will be fairly low (but not the uA level available from sleep). I suspect this will be as good as you can get if you want to re-awaken from a CAN module.

Best Wishes