ATMega169P wakeup problem

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

Hi,

I have a device (remoteRF) built with ATMega169P micro and 3 digit LCD. There is a 3 key keypad with wake on interrupt on change. All works nicely with one exception. When left for more than ~6 hours it takes a few seconds to wakeup on keypress (and it should be a matter of ms rather). Any help/ideas would be appreciated.

Jan

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

janek wrote:
Hi,

I have a device (remoteRF) built with ATMega169P micro and 3 digit LCD. There is a 3 key keypad with wake on interrupt on change. All works nicely with one exception. When left for more than ~6 hours it takes a few seconds to wakeup on keypress (and it should be a matter of ms rather). Any help/ideas would be appreciated.

Jan

OK, found the problem. It should be listed under errata for the ATmega169P. The Interrupt on change doesn't work reliably on ATmega169P. This might save time for other people.

Jan

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

Quote:

It should be listed under errata for the ATmega169P. The Interrupt on change doesn't work reliably on ATmega169P.

???
Quote:
34. Errata
34.1 ATmega169P Rev. G
No known errata.
34.2 ATmega169P Rev. A to F
Not sampled.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

solving problem by denying it's existence?

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

No, asking where you got this valuable information, how you reproduced it, what was Atmel's response, when did Atmel say they would add it to the errata--the kind of stuff that 'Freaks want to know.

It is also curious, as I have a series of production apps that use pin-change on the Mega169 for counting flowmeter pulses. As there are multiple flowmeters on a system when in full operation at rated max flow rate I'm processing 1000+ pin-change interrupts each second. As the end use customers expect accuracy, I would have expected a lot of reports if in my systems

Quote:

The Interrupt on change doesn't work reliably
.

Now, this is with the venerable '169. We are preparing for another build of controller boards, and will probably use '169P or '329P. So you see that I am directly interested to hear of your experiences, any documentation, and a description of the test setup to reproduce the situation.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

Lee,

I use Interrupt on change to detect keypreses.
The wakeup problem only occured when the system was left in powerdown mode for longer than approx. 6 hours.
I think you are safe as you have a different scenario.
The Int on change actually always occured, but it took a very long time to wakeup the system into normal mode.
I fixed the problem by firing timer2 interrupt from interrupt on change ISR.
If you look at the table with power modes for ATmega169, there is no INT on change listed as wakeup source from powerdown mode.
All the best with your project.

Jan

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

I don't know what you mean by INT on change.

Pin change interrupts work in powerdown sleep. So does an external low level interrupt on INT0.

If they fail to work after 6 hours of sleep, that would be news to all of us.

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

Lee,

I mean Pin Change interrupt.
Sorry, I actually use Power-save mode with LCD working.
Again, my experience is that although Pin Change interrupt occured always when invoked it took quite a long time to wakeup from Power-save mode into normal mode (I use RC clock 8MHz/8).
But maybe I was/am doing something wrong.
I have a problem fixed by using timer2 as a wakeup source, and as I have spent some time on the issue, I am happy with having the system working now.

Jan

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

Quote:

Again, my experience is that although Pin Change interrupt occured always when invoked it took quite a long time to wakeup from Power-save mode into normal mode

How can it be the AVR that is causing a long delay, when the main clock is still running and the LCD being refreshed?

Could you be causing cascading interrupts, such as a bouncy switch into the pin-change ISR without hardware debounce and/or disabling the pin-change? With a series of bounces and lengthy wakeup coder and executing one mainline instruction per ISR servicing? That might explain the situation.

Or some cap or other voltage level is slowly decaying over the sleep time, and takes a while to charge back up?

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

Lee,
In Power-save mode only asynchronous clock is running (32768Hz watch crystal used). I use internal RC clock 8MHz/8 as main system clock.
Jan

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

Yes, but if the LCD is running, it is generating interrupts at 32 Hertz, or faster. This causes the CPU to run 32 times per second to service the interrupt.

The LCD interrupt handler can be used to decrement a timer to debounce the key presses. That's what Atmel does in their Butterfly program.

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

Lee,

I do it differently and maybe it was my problem.
Next time I will study the existing solutions.
Good luck with your project.

Jan