[ commit ]
This seems like quite a random fix, but calling rtc.standBy() only works from within setup() and loop(), and not from the RTC ISR. There is probably something happening behind the scenes, perhaps enabling/disabling of writes to protected registers. Its still weird that calling standBy() from the wrong routine just appears to stall the processor.
The revelation of the night was realizing that SAMD21 did successfully wake up after the first alarm, but it wasn’t going into loop() right after (indicated by missing LED flashes!) I was calling standBy() from the same alarmConfig() function: but it was first being called from setup(), and subsequently from within the RTC ISR. That’s why the first alarm always worked, but things messed up during its servicing (as soon as we hit standBy()).
Aside: delay() crashes inside the ISR too.
On the brightside (go Killers!), I am now more comfortable with writing SAM’s registers through the Arduino IDE. Still, using a debugger along with Atmel Studio would probably make development *much* faster. I now appreciate TI’s putting the XDS debuggers on all their eval boards. Well, Arduino Zero has that too, but Adalogger is too compact to allow that!
I just wish that re-enabling the Serial module again after wake-up was working. But since that’s not an end-user requirement, I’m going to put RTC on hold and get back to the SD. We could then come back to the RTC code so that the config. packet could be generated from a GUI.
Another interesting thing would be to store the alarm times in flash memory (SAMD21’s “EEPROM”) over just RAM – but I doubt that that would be useful unless I can guarantee that the RTC wouldn’t lose time during an accident. The idea is that if somehow the watchdog caused a reboot (is the watchdog setup anyway?), it should still be able to alarm – but we don’t want all the times to be skewed!
Hypothetically speaking, there could be a routine running every so often that writes the current time (and maybe even the next alarm’s index) to flash. Its just that this recorder would have to brave through weeks of work without human contact, and a little robustness might save us the frustration of looking at missing records on the SD later 🙂