When changing the clock configuration while the RTC is running, the
RTC may end up in an undefined state that leaves it unresponsive.
The RTC is not reset to stay persistent across reboots/hibernate, so
it will not be reset on init.
Instead, disable the RTC while configuring the clocks, rtc_init() will
take care of re-enabling it.
@dylad introduced this workaround for saml21, samd5x needs it too.
To reproduce, set the CLOCK_CORECLOCK of a samd5x board (e.g. same54-xpro)
to 48 MHz.
Run any RTC application. The CPU will be stuck in _wait_syncbusy() after
a reboot.
This patch will fix this. (You will need to power-cycle the board if the
RTC has entered the stuck state as it will never be reset.)
Due to stability reasons, the SoftAP interface of the WiFi module was always enabled in former versions even if only the station interface was used. Therefore the WiFi modem had to be always active and the SoC could not enter the modem sleep mode. Therefore, the SoftAP interface is only enabled when ESP-NOW is used.
When entering a sleep mode, all wake-up sources should first be disabled before the wake-up sources required for the sleep mode are then stepwise enabled again. Otherwise, an wake-up configuration of one sleep mode may affect the wake-up within another sleep mode.
This file used to be part of the toolchain (at least in 2016.05-03
version) but is not part of the current MIPS toolchain (2018-09-03).
Signed-off-by: Francois Berder <18538310+francois-berder@users.noreply.github.com>
The ROM size is encoded in the part number of the Atmel SAM chips.
RAM size is not encoded directly, so get it by parsing the chip's vendor file.
The file remains in the page cache for the compiler to use, so the overhead
should be minimal:
on master:
Benchmark #1: make BOARD=samr21-xpro -j
Time (mean ± σ): 527.9 ms ± 4.9 ms [User: 503.1 ms, System: 69.6 ms]
Range (min … max): 519.7 ms … 537.2 ms 10 runs
with this patch:
Benchmark #1: make BOARD=samr21-xpro -j
Time (mean ± σ): 535.6 ms ± 4.0 ms [User: 507.6 ms, System: 75.1 ms]
Range (min … max): 530.6 ms … 542.0 ms 10 runs
- Since flash access is shared with CPU2 we resize ROM_LEN
according to CPU2 secure flash memmory area.
- Add assert to prevent unauthorized reads from CPU2 secure
flash area
