Regarding the EEEPROM writes, I realize that the EEPROM can be written only 100.000 times, but as I said, these are for debugging only. Once I know what’s going on I’ll throw them out again. Also the flash can be written only 10.000 times, and at the rate I’m reflashing the device right now, I might easily hit that limit first.
Do you have anything connected to the reset pin? When the problem happens, do you still have a healthy steady voltage on the 5V pin? What are the symptoms that make you conclude it is resetting itself?
I have a 10k pullup to VCC and a 100nF to ground, as seen in the schematic. I haven’t measured the voltage on the reset pin yet, I’ll do that next time the bug strikes. The conclusion that it’s resetting itself comes from the counters in the EEPROM: The counters for wakeup, sleep and button presses represent the actual number of times these events happened, while the reset counter is through the roof.
Apart from the number of EEPROM writes, I can see a few possible issues:
You are enabling the pin change interrupt before you configure the pins. Do it the other way round, i.e. set up the pins as inputs (and you could use INPUT_PULLUP mode instead of writing HIGH to the port), and only then enable the pin change interrupt.
As you are using the watchdog, you should reset and disable it at the beginning of setup().
In my experience, reset loops are usually caused by using the watchdog incorrectly.
I’ll try changing the order of enabling the interrupt and enabling the internal pullups. I tried using INPUT_PULLUP but my version of Arduino does not seem to support it.
Ironically I used the watchdog because I suspected the process of setting up the RFM12 and sending my garage door opening sequence to hang (it takes quite long, about 300ms). Maybe I replaced one problem with another…
I’ll try and do what you told me, but I don’t really understand what that’ll change exactly. Could you go a bit more into the theory behind that or point me to some documentation?