Waking up from SLEEP_

Hello I am quite new to Arduino, but I have some embedded knowledge from using other uC’s

I am putting my device to sleep (SLEEP_MODE_PWR_DOWN) and then when waking it up via Interrupt on pin two, I see some strange behaviours with my enum StateMachine variable.

I do not change its value and Prior sleep serial.print shows 4 i.e. STANDBY after wake up it goes to an undefined value?

/UPDATE/
I tried to bodge and assign back CurrentState=STANDBY; In the ISR call but this doesn’t seem to work, it feels to me like the definition of the enum is vanished?!

Has any one seen similar issues or has any suggestions?

Many thanks
Eryk

enum StateMachine {
	//State of the Device
	VIBRARTION_1,
	VIBRARTION_2,
	VIBRARTION_3,
	COOLING,
	STANDBY,
	BATTERY_CHECK,
	CHARGING
	
};

StateMachine CurerntState = STANDBY;
void GoToSleep(){
	  attachInterrupt(digitalPinToInterrupt(BUTTON_PIN), wakeupISR, FALLING);
	  delay(100); 
	  set_sleep_mode(SLEEP_MODE_PWR_DOWN); 
	  sleep_enable();
	  sleep_mode();
	  sleep_disable();
}
void wakeupISR() {
	detachInterrupt(0); 

	
}

You haven’t posted all your code or the output from the serial console so it is not clear if this is the issue, but you get garbage from Serial.print on wakeup if the serial buffer was not flushed properly before sleep.
That could give the symptoms of the undefined value you refer to.

Thanks for the advice, I stumbled across this problem but fixed it already...

I know the value is wrong as the code doesn't run properly after sleep anymore when it gets to switch(CurrentState){};

Is your state declared as volatile if you are messing with it in the ISR?

I don’t see any code that changes or reads StateMachine so your question doesn’t make any sense.

http://snippets-r-us.com/

Please edit your post, select the code, and put it between [code][/code] tags.

You can do that by hitting the “Code” icon above the posting area. It is the first icon, with the symbol: </>

How to use this forum

Thank you for your opinion, if it make no sense to you then maybe the problem is out of your area of expertise, I am sorry but don't appreciate your tone...

switch(CurrentState){...}

J-M-L:
Is your state declared as volatile if you are messing with it in the ISR?

I see, let me try that sound possibly like the reason …

PencilDH:
Thank you for your opinion, if it make no sense to you then maybe the problem is out of your area of expertise, I am sorry but don't appreciate your tone...

switch(CurrentState){...}

Yes, but you appear to have edited the original post in the meantime to add such details retrospectively.
If you went to all that trouble, why didn't you simply add all your code, as you were asked to, so that you could be more easily helped, instead of making attempts to question the knowledge of other forum members ?

@pencil -

Your question was

Has any one seen similar issues or has any suggestions?

I think you should take the advice as they come. The suggestion was to properly use the forum, to post full code and not let contributors do the guess work.... Not seeing what you do does not help provide guidance. the volatile idea is one possibility but there could be hundred others.

PencilDH:
Thank you for your opinion, if it make no sense to you then maybe the problem is out of your area of expertise, I am sorry but don't appreciate your tone...

there was a please in his answer.. and You can read his web site if you want to learn more about power savings or about interrupts... You'll see he knows probably way more than you do...

PencilDH:
Thank you for your opinion, if it make no sense to you then maybe the problem is out of your area of expertise, I am sorry but don't appreciate your tone...

switch(CurrentState){...}

You don't even know why it's important to post your full sketch and you're dissing Nick? On top of that you can't even give an adequate description of your problem. You say you see strange results from Serial prints, but you don't show a single of of those print statements in the snippets you gave us.

it isn't even a matter of forum rules, those things are Debugging 101. Here's the code, this is what I want to happen, and this is what actually happens.

It is also bad manners on pretty much any forum to substantially edit a post after people have replied to it.

I have some embedded knowledge from using other uC's

And yet you apparently have no grasp of even the most basic principles of debugging a program, and your response to a request for clarification is to insult the intelligence one of our most respected members.

J-M-L:
@pencil -

Your question was

I think you should take the advice as they come. The suggestion was to properly use the forum, to post full code and not let contributors do the guess work.... Not seeing what you do does not help provide guidance. the volatile idea is one possibility but there could be hundred others.

there was a please in his answer.. and You can read his web site if you want to learn more about power savings or about interrupts... You'll see he knows probably way more than you do...

@ J-M-L
Thanks volatile was the issue, now things work well -

regarding the comment sorry but I don't take well if people seem to be hostile and stuck up, clearly you have understood the problem by my decription - so it made sense no?

As taking onboard what he said, I did and edited the code comments as it was a fair pointer

Jiggy-Ninja:
You don't even know why it's important to post your full sketch and you're dissing Nick? On top of that you can't even give an adequate description of your problem. You say you see strange results from Serial prints, but you don't show a single of of those print statements in the snippets you gave us.

it isn't even a matter of forum rules, those things are Debugging 101. Here's the code, this is what I want to happen, and this is what actually happens.

It is also bad manners on pretty much any forum to substantially edit a post after people have replied to it.And yet you apparently have no grasp of even the most basic principles of debugging a program, and your response to a request for clarification is to insult the intelligence one of our most respected members.

If your read my post thats what it said, fair enough I didn't format it and I take that - but the description was clear enough that a member of this community managed to figure the problem out without making rude remarks.

Yes I don't have any idea about debugging - I usually look in to registers via my JTAG not serial print data

PencilDH:
Thank you for your opinion, if it make no sense to you then maybe the problem is out of your area of expertise ...

switch(CurrentState){...}

Yes, possibly this is way over my head. :slight_smile:

However the code you quoted does not change CurrentState.

I tried to bodge and assign back CurrentState=STANDBY; In the ISR call but this doesn't seem to work ...

I don't see you changing CurrentState in the line above or anywhere in your post (including the ISR).

... it feels to me like the definition of the enum is vanished?!

The definition vanished. I see.

Hi there, its because it was not supposed to be changed in this scenario, I wasn't changing it and after sleep it was changed, but it makes sense that it disappears when you power off some of the chip's memory... All sorted now thanks

PencilDH:
Hi there, its because it was not supposed to be changed in this scenario, I wasn't changing it and after sleep it was changed, but it makes sense that it disappears when you power off some of the chip's memory... All sorted now thanks

I do not believe that invoking sleep level SLEEP_MODE_PWR_DOWN will cause memory contents to disappear because the processor should wake up with the same context that was present when the sleep was invoked.

PencilDH:
Hi there, its because it was not supposed to be changed in this scenario, I wasn't changing it and after sleep it was changed, but it makes sense that it disappears when you power off some of the chip's memory... All sorted now thanks

It doesn't make sense at all. When in sleep mode (as opposed to cutting power to the chip altogether) then RAM is preserved. From the datasheet:

If an enabled interrupt occurs while the MCU is in a sleep mode, the MCU wakes up. The MCU is then halted for
four cycles in addition to the start-up time, executes the interrupt routine, and resumes execution from the
instruction following SLEEP. The contents of the Register File and SRAM are unaltered when the device wakes
up from sleep. If a reset occurs during sleep mode, the MCU wakes up and executes from the Reset Vector.