PCINT is delayed while in deep sleep

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

Hello,

 

I am using the ATMEGA1284P in our project

To be able to detect incoming SMS event from a modem while in SLEEP_MODE_PWR_DOWN. I change the behaviour of the RX pin from UART config to PCINT.

This works fine in many cases, but unfortunatly not always.

What I have discovered by measuring this with a scop is that the PCINT is not detecting edges as quick As i want it to.

If the UART stream is to short the PCINT interrupt is not able to detect the signal changes. It seems like it need up to 11 mS.

So with the short prefered URC msg I am not able to detct it.

With a longer URC which contain the hole SMS msg I am able to detect it. Unfortunatly configuring with this URC will not enable the modem to store it in the modems internal memory for later on readout to parse what the SMS info actual is. 

 

So my main question is, is it correct that a PCINT interrupt has some kind of latency during POWER DOWN SLEEP?

 

Br Ellile     

Br Leif G

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

ellile wrote:
It seems like it need up to 11 mS.
What is the clock source of the AVR - how long does it take to wake up? For example, if you use a crystal it can take a while for the oscillator to resonate. What a lot of people do in such designs is actually use the internal RC oscillator as the main clock as it is very fast to start. But, because it is inaccurate, use a secondary crystal to calibrate it form time to time (making OSCCAL adjustments).

 

BTW I seem to remember there may be some more recent AVRs that UART Start as a possible wake up source? They may well have mechanisms to handle this better anyway.

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

Hi Clawson,

 

My clock sours is a HC49 4Mhz and baudrate is 38,4k.

About the wakeuptime I am a littlebit unsure as I am proberly not able to indicate when I actual has a wakeup.

My fuse settings is = fd90fe

Br Leif G

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

ellile wrote:
My fuse settings is = fd90fe

You could decode that for us.  What does the datasheet say about wakeup time with a crystal with those settings from powerdown?  16K clocks?  How long is that at 4MHz?  4ms?  How many characters is that at 38400?  Let's see -- that is 26us per bit; 260us for a 10 bit character frame.  About 4 bytes per millisecond, so about 16 bytes in the 4ms startup time?

 

Note that you are unlikely to reliably start from deep sleep and get the first character even with a faster wakeup time.  Run the numbers...  As mentioend, there are newer generation models that have start-bit detection.

 

 

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

ellile wrote:
I change the behaviour of the RX pin from UART config to PCINT.

Hmmm--I'd have to experiment a bit, but you might be able to do both?  Even with the UART "taking over" the pin, I believe that the PINx register will still read properly.

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


theusch wrote:
You could decode that for us.
I *think* it probably means:

 

 

If I got the 3 bytes in the right order.

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

Thanks for the feedback

Sorry about that. I was in the middle of a test and was not able to take a readout. Her it is

 

BOD=1,8V

JTAGEN

SPIEN

BOOTRST

ExtOsc 3-8Mhz Startup time 16K CK + 65mS

 

So with 16K ck I have as you mentioned 4mS startup. And the aditional 65ms I assume is related to the delay at reset. 

The message I want to detect edges from is

+CMTI: "ME",8

And this represent approx 4 to 5 ms so from that I have an issue

But I still find it strange that I do not see any PCINT interrupt before after 11mS of pin change edges on the pin before I toggle a LED inside the ISR handler.

 

Thanks for the clarification. But unfortunatly a little drawback, hmm.

I do hope that the UBLOX modem are able to send me the longer message as the +CMT ... string. And still stores the SMS inside the modem for me to readout later.

 

For your information. This is already a product produce in large scale so A change of mcu is not a topic at this stage. But new MCU is comming :) 

Br Leif G

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

ellile wrote:
But I still find it strange that I do not see any PCINT interrupt before after 11mS of pin change edges on the pin before I toggle a LED inside the ISR handler.

Tell how you are determining that.  Show a schematic and the complete source of a test program that demonstrates your situation.

 

If indeed you are disabling UART functions as you hinted to use the PCINT, then you will have no chance of seeing the first few characters properly.

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


I never parse any UART messages when in deep Sleep. I only count edge changes in PCINT ISR func handler. And when above a sufficient amount I count this event as an SMS URC from the modem.

I then wake up and request the modem for all incoming SMS which is stored in the modem.

Blue faling edge is when the PCINT ISR detect an edge change in the yellow plott. But as you see it needs11mS to detect this. 

NB!! This is with another URC message for testing purpose and not the one I want to use. (ignore green plott)

 

 

But do you think that I am able to get around my issue if I enable PCINT at same time as UART is enabled?

 

Br Ellile

 

Br Leif G

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

What happens if you change AVR clock from Xtal to int RC (ignore the timing error for now - you aren't going to actually read the UART data)

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

Ill try

 

Br Leif G

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

Is this requiring change in Fuse settings or could this be done in FW?

Br Leif G

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

ellile wrote:
Is this requiring change in Fuse settings or could this be done in FW?

a clock source change will require a fuse change,

How about changing sleep mode to Idle mode, does that  change your delay?

 

Jim

 

Click Link: Get Free Stock: Retire early! PM for strategy

share.robinhood.com/jamesc3274

 

 

 

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

I will try that one to. Such change will proberly increase the current consumption so if working I will compare that parameter.

Br Leif G

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

 

I have never seen the PRR0 and PRR1 reg before. And maybe perfect for my use case. So could I use those regs togheter with Idle sleep mode and actual make my self a custom power down sleep mode?

Wher I keep clock IO but stop the other perifere. Anyone that have tried this before? Or Am I of track on this one :)

 

 

 

 

Br Leif G

Last Edited: Tue. Jun 25, 2019 - 08:34 PM