Due to the RIOT_EPOCH of 2020 this overflow will happen in year 2084. It would be scary if IoT devices are still around then.
We can save RAM and ROM. Furthermore, this overflow handling should block BACKUP power mode in order to keep track of the reference year.
`rtt_get_counter()` already waits for syncbusy before reading the time,
but we also have to do this in RTC mode (`rtc_get_time()`) to avoid
reading old values.
Thus, always wait for syncbusy to clear when accessing the COUNT register.
This allows to use the sam0 RTT together with the rtt_rtc module.
The idea is to use RTT as a monotonic counter, but still keep track
of the time with the virtual RTC module.
If we configure TAMPCTRL early, GPIO events will set bits in the
TAMPCTRL register.
That means that after a wake-up, we can't tell if the bit was set
because it was the wake-up source or if it was already set by a
run-time GPIO event.
Errate 2.17.4 says:
> Upon enabling the RTC tamper detection feature, a false tamper
> detection *can* be reported by the RTC.
It turns out that this spurious event is not always generated.
If RTC alarm is used and the CPU was previously woken from hibernate
by RTC, it *can* happen that the false tamper event is *not* generated.
In this case, we will block indefinitely on the mutex.
To solve this, add a timeout to the event.
Also poll the event instead of using a mutex, as we have already set
`PM->SLEEPCFG.bit.SLEEPMODE` at this point.
The RTC and RTT share the same peripheral, so they can also
share the same code.
This is needed to integrate the Tamper Detection into common
RTC/RTT code.
