On SAM L21 only 8 EXTWAKE pins can wake the CPU from Backup sleep.
Handle this analogous to the RTC tamper pins on SAM D5x/E5x where
configuring them as an interrupt will also cause them to wake the
device from Deep Sleep.
The sam0 rtt busy loops for 180us every time an alarm is set or
the counter is read, this propagates and leads to timing errors
on ztimer_msec that are higher than > +-1msec.
The same goes for fe310.
This introduces KCONFIG_BOARD_CONFIG and KCONFIG_CPU_CONFIG variable for
boards and CPUs (including common directories) to add default
configuration files to be merged. The current approach, as it uses
Makefile.features, would include boards first, not allowing them to
override CPU configurations.
Setting up a DMA transfer can take longer than sending out a buffer
byte by byte if the buffer is small.
DMA only shows advantages for large buffers, using it for every transfer
will cause a net slowdown.
Since we did not come up with a good way to determine the treshold based
on the SPI frequency, just use a fixed buffer for now so that DMA can be
used without slowing things down overall.
In Asynchronous Fractional baud rate mode, the baud rate can not be
greater than the source frequency divided by the oversampling (8, 16).
Currently we are always using 16x oversampling.
This makes it impossible to e.g. set a 2 MHz UART baud rate on the 16 MHz
`saml10-xpro`.
With this change, the oversampling is automatically reduced to 8x which
allows us to set 16 MHz / 8 -> 2 MHz baud rate.
SERCOM5 on SAM L21 does not support fractional baud rate mode.
Instead of special-casing it, just use arithmetic baud rate mode
in general on this CPU, as I'm not sure what the advantages of fractional
baud rate mode are.
fixes#16692
In case of network heavy traffic on the Ethernet, interrupts
fire faster than the netdev thread can process them and we
run out of buffers. With this commit, we now check if we
don't have buffers available, so we can flush everything and
restart reception properly even if we did drop a few in the
operation
When using the I2C_NOSTOP flag the bus should remain in control.
The current check assumes it must go to idle when reading.
This adds a condition checks if the nostop flag is active
and expects the bus status to be the owner of the bus.
This reverts commit 585dc15f99.
I did misunderstand this feature: This only inverts the data
bits (instead of `c` uart will transmit `~c`), not the whole
line level.
This is not very useful on it's own, so revert it.
The RTT overflow callback is not available on all RTT implementations.
This means it is either a no-op or `rtt_set_overflow_cb()` is a no-op
or it will overwrite the alarm set with `rtt_set_alarm()`.
This adds a feature to indicate that proper overflow reporting is available.
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.
Some periph_rtt implementations do not provide `rtt_set_counter()`. This
adds `periph_rtt_set_counter` as feature to allow testing for its
availability. The feature is provided at CPU level if periph_rtt is
provided by the board for all CPUs implementing `rtt_set_counter()`.
Some periph_rtt implementations do not provide `rtt_set_counter()`. This
adds `periph_rtt_set_counter` as feature to allow testing for its
availability. The feature is provided at CPU level if periph_rtt is
provided by the board for all CPUs implementing `rtt_set_counter()`.
The ADC SYNCBUSY.SWTRIG gets stuck to '1' after wake-up from Standby Sleep mode.
Ignore the ADC `SYNCBUSY.SWTRIG` status bit, this functionality is not used by
the driver anyway.
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 DAC can have some start-up delay.
If we try to write to it before it's ready, it will get stuck.
This happens now that `tests/driver_dac_dds` immediately sets a DAC
value after init.
The samd2x class of MCUs doesn't have this bit, but a quick test on
samd10 shows that it might not be nececary there - the DAC does not
get stuck when writing to it immediately after init.
`flashpage_write_raw()` got renamed to `flashpage_write()`.
Now `sam0_flashpage_aux_write_raw()` is the only remaining 'raw'
function, even though it behaves just like `flashpage_write()`.
So let's also rename that for consistency.
On samd5x only the RTC can wake the CPU from Deep Sleep (pm modes 0 & 1).
The external interrupt controller is disabled, but we can use the tamper
detection of the RTC.
If an gpio interrupt is configured on one of the five tamper detect pins,
those can be used to wake the CPU from Deep Sleep / Hibernate.
