Arduino Pro Mini doesn't go back to sleep

Hi,
I have a few questions about the sleep mode of the Arduino Pro Mini.
I am measuring the temperature and humidity with an HTU21D and that info is only measured when the Pro Mini wakes up. The problem is that the Pro Mini wakes up but it stays awake and doesn't go back to sleep.
If I use a different code then the Pro Mini wakes up and goes back to sleep like it's told so i'm a bit confused here since I can't find a lot of differences between the two programs.

This is my own program where the Pro Mini wakes up and stays awake
StLaurens_Arduino_smart-home_sleep-modus_V3.ino (19,7 KB)

This is the program where the Pro Mini wakes up and goes to sleep like it's told
StLaurens_Arduino_duty_cycle_measurement_sleep-modus_V1.ino (15,4 KB)

That's an awful lot of code for someone to go through to isolate the sleep stuff. All I can suggest is that you insert some serial output at various points in the code that will tell you what is being executed and what isn't.

You don't have to do this every time before going to sleep

attachInterrupt(0, wakeUp, LOW);                       //use interrupt 0 (pin PD2) and run function wakeUp when pin 2 gets LOW

Just enable it once in setup(). Here's the low-level code to enable PIND2 for falling edge trigger

void setup()
{
	// INT0 on PORTD2
	// set input and enable pull-up
	DDRD  &= ~(1<<PORTD2);
	PORTD |=  (1<<PORTD2);

	// falling edge interrupt on INT0
	EICRA = 1<<ISC01 | 0<<ISC00;
	EIFR  = 1<<INTF0;
	EIMSK = 0<<INT1 | 1<<INT0;
}

You then just use the INT0 vector

ISR(INT0_vect)
{
	asm("NOP");
}

instead of

void wakeUp()        // here the interrupt is handled after wakeup
{
}

Lastly, you can use the low-level code to go to sleep (POWER_DOWN)

asm("NOP");
SMCR = SLEEP_MODE_PWR_DOWN | 1<<SE;
asm("NOP");
asm("SLEEP");
asm("NOP");

I was going to suggest some things, but if the example code works, then my objections probably aren't relevant. Anyway, like hzrnbgy, I was going to suggest you use FALLING instead of LOW, and that you put the "detach" command down in the ISR. But the example doesn't do either of those things, and still works, so I don't know.

If the interrupt-related code really is the same in both sketches, then I wonder if you are running into a ram problem of some kind, particularly with all the floats. You might try commenting out one of your function calls at a time, and see if at some point it starts working. That might indicate where the problem is.

But I would start with serial printing the value of goToSleepNow at the very top of the loop. That would tell you if you are getting back there after the first interrupt occurs, and if that value is TRUE.

Also, I wonder how you know it is staying awake rather than going to sleep but waking up immediately. The "interval" variable is different in the two sketches, so I wondered if this might just be a timing issue.

Avoid attachInterrupt() when you can (which, when you're using the interrupt to wake from sleep, you can, because you know where execution will resume from when you wake up). attachInterrupt is heinously inefficient.

Don't use

ISR(SOME_VECTOR_vect) {
asm("nop");
}
  1. The asm is unnecessary, all it does is waste a clock and 2 bytes with a NOP that you don't need.
  2. Don't do ISR(SOME_VECTOR_vect){;} either. You still waste 18 bytes and and 14 clocks with a prologue and epilogue that you don't need (That will generate: push r0, push r1, in r0, SREG, push r0, eor r1, r1, pop r0, out SREG, r0, pop r1, pop r0, reti. Instead, use EMPTY_INTERRUPT(SOME_VECTOR_vect) - which will generate just reti

And (on the topic of how not to do ISRs. if you need two identical interrupts (including identical empty interrupts), use ISR(SOME_OTHER_vect, ISR_ALIASOF(SOME_VECTOR_vect)); which has zero overhead...

I did what you recommended and first i found out that the part of LoRaSend was the issue. Now i have been able to fix it but i don't think it's the right way to fix it.

At the bottom of "void LoRaSend" is a LoRa.endPacket and it's bc of that part that it doesn't go back to sleep so for now i have deleted the LoRa.endPacket and it works fine now. I just don't think that it's the right way to fix it. Do you perhaps have any ideas on how to fix it?

I don't know anything about LoRa or its library. I'd suggest you go through the examples in the library, and see if your code does it the way they do.

Is it actually sending anything if you remove that line?

I've checked some LoRa examples and for most sender codes they all had LoRa.endPacket except for one where it was LoRa.endPacket(true). I decided to give that a try and now it ends the packet, send the packet and my pro mini goes back to sleep.

I thank you for your help!

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.