Wake on uart rx

Go To Last Post
16 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi. I want to wake up on uart receive.
I tied rx to INT0, which works fine in the sense of only waking up.
However, my received characters after wake up are crazy random characters (some framing error likely - but the uart error register says everything is fine).
Anyone know how to receive reliably out of sleep mode?
I'm trying to play with sleep modes POWER DOWN and STANDBY
With stand by I need to wait for crystal to stabilize though. I might be willing to even go to a baud rate of 7 if necessary.... At least to see if that works! Right now I do have 65ms startup time selected. But with standby mode, that's a 6 cycle wake up. I have 4mhz crystal. It SHOULD wake up and receive everything fine!
Any ideas? What am I missing here?

Atmega644 FYI

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Can you control the other end's behaviour? Like having it send some "oi, wake up!" garbage to get things started before it passes the real message?

The problem with crystals is that they need time to start resonating if they are not already clocking.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

And, during that clock stabilization time, the USART may not be running at the proper baud rate. So, what you receive may be very suspect.

I would send a "wakeup character", wait a time governed by how you set the SUT fuses, then send the real message.

Alternatively, sleep in one of the modes where the clock remains running.

A third choice which might still require a wakeup character, but a much shorter wait, would be to use a ceramic resonator. Startup is much faster than with a crystal. You would need to change the SUT fuses, accordingly.

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hmm. Well the powerdown sleep mode should work (oscillator still runs).
I don't have the ability to send a wake up character. It's uart coming out of a gsm module, so ever SMS costs money!
Can you please elaborate as to why the uart would not be running at the correct baud rate (even when the oscillator doesn't go to sleep?)?

I'll show you some output when I get home of what I'm sending/receiving. It's almost ridiculous and I can't make sense as to why it would be happening. Code to come as well!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If the oscillator does not turn off, the should be no speed problems. And, it should wake up in less than one character time (at any modest baud rate). Do you have the correct number of characters?

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Well the powerdown sleep mode should work (oscillator still runs).
No, in powerdown the main clock is off.

I have tested Idle mode, wake by RX interrupt, mega88.
Works well.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok well. Main code:

	while(1)
	{
		uartSendString("Getting sleepy...\r\n");
		_delay_ms(100);
		gotobed();
		uartSendString("Woke up to: \r\n");
		while(uartContents) 
		{
		    uartReadChar(&t);
			uartSendChar(t);
			uartSendString("\r\n");
		}

		uartSendString("\r\n");
		uartSendString("Uh oh...\r\n");
	}

I send a binary file that contains the numbers associated with the character string "123456789".

POWER DOWN MODE (dead oscillator)


Getting sleepy...
Woke up to: 

¢
ª
²
º
Â
Ê
þ

Uh oh...
Getting sleepy...

In STANDBY mode (oscillator alive):


Getting sleepy...
Woke up to: 
1
2
3
4
5
6
7
8
9

Uh oh...
Getting sleepy...

Obviously one works and one doesnt. However, the results are REPEATABLE.

So, my new question is: Why doesnt it eventually sync up in power-down mode??

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

17.8 Asynchronous Data Reception describes what goes on during a receive, so if the master clock has not stabilised it is likely that you will get incorrect decoding of the start, data and stop bits.
If you have a incomming stream of characters using 1 stop-bit with no time-delays between each character then if a start-bit is missed it can effectively shift the incomming bit-stream and produce garbage.

From the datasheet

Quote:
8.7 Standby mode
... This mode is identical to Power-down with the exception that the Oscillator is kept running

But what greatly puzzles me is how the USART can actually receive anything, because it uses the CLK I/O (7.1.2 in the datasheet) and CLK I/O is not active in power-down or standby modes (Table 8-1)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Interesting. So if each character was separated by some fixed time delay, I imagine I would eventually get synced up. Right?

To answer your puzzlement though, I have a 220Ohm resistor across RX and INT0. The processor wakes on the INT0 level drop.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

mikech wrote:
But what greatly puzzles me is how the USART can actually receive anything, because it uses the CLK I/O (7.1.2 in the datasheet) and CLK I/O is not active in power-down or standby modes (Table 8-1)

The USART clock is derived from fosc:

Datasheet wrote:
19.4.1 Internal Clock Generation – The Baud Rate Generator Internal clock generation is used for the asynchronous and the synchronous master modes of operation.
The description in this section refers to Figure 19-2 on page 176.
The USART Baud Rate Register (UBRRn) and the down-counter connected to it function as a programmable prescaler or baud rate generator. The down-counter, running at system clock (fosc), is loaded with the UBRRn value each time the counter has counted down to zero or when the UBRRnL Register is written. A clock is generated each time the counter reaches zero. This clock is the baud rate generator clock output (= fosc/(UBRRn+1)).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
But what greatly puzzles me is how the USART can actually receive anything, because it uses the CLK I/O (7.1.2 in the datasheet) and CLK I/O is not active in power-down or standby modes
You do not receive during sleep but after wakeup. And then the CLK I/O is active.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Chuck99 Yes., I did see that running at system clock (fosc) but I interpreted that to mean that the frequency was the same as the system-clock.

Visovian Yes., that is correct.
What was puzzling me was how the wakeup could occur if the clock to the USART was stopped.

tkurowski Ahh... so INT0 is doing the wakeup !
If the GSM modem had a slight time-delay between each character it would synchronise better, (but you'll probably still have scrambled characters until the clock stabilises)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
but to receive a character, the clock
in the USART must be running., so either the datasheet is inconsistant, or CLK IO is used for something else in the USART.
I do not understand.
In the moment of receiving the chip is awaken, out of any sleep mode, all cloks run, so why UART should not work.
The only problem is that in modes when main clock is stopped, it takes the osc. relatively long time to stabilize after wake up.
That is why powerdown mode fails.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sigh... I really should read everything in the messages.
In the very first message I skipped-over the

Quote:
I tied rx to INT0, which works fine in the sense of only waking up.
sentence and therefore became puzzled as to how the USART could wake up the processor.

My apologies.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It's all good. Thanks for the input everyone! I'll see if the gsm module has a pause function. Otherwise I'll have to stick with stand by mode. I'll tell you how it goes!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So theres no delay-between-characters option. Gotta go with stand by mode.

Thanks again guys/girls.