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.
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.
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");
}
The asm is unnecessary, all it does is waste a clock and 2 bytes with a NOP that you don't need.
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'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.