This caused a conflict. As CMSIS update introduced low level init, lets use the types
from CMSIS. We could potentionally use __cmsis_start but as I saw for some targets,
the init routine is slightly different. So rather keep what we have in targets, and just
use types already defined in CMSIS.
Consider the following factors to define WDT reset delay:
1. Cannot be too small. This is to avoid premature WDT reset in pieces of timeout cascading.
2. Cannot be too large. This is to pass Greentea reset_reason/watchdog_reset tests, which have e.g. 50~100 reset delay tolerance.
Original implementation doesn't enable watchdog reset in pieces of cascaded timeout, except the last one. This is to guarantee re-configuration can be in time, but in interrupt disabled scenario e.g. Hard Fault, watchdog reset can cease to be effective.
This change enables watchdog reset all the way of cascaded timeout. With trade-off, guaranteed watchdog reset function is more significant than re-configuration in time.
Relevant modifications:
1. Support degrading QSPI0/1 to SPI4/5 for normal SPI transfer
2. Fix with BSP crypto driver API change
3. Fix with BSP PDMA driver API change
4. Make necessary modifications to pass FPGA CI Test Shield tests
5. Don't distinguish pinmap among parts e.g. M480 LG. Application users must take care.
Most code doesn't check return code of CLK_WaitClockReady(...). Enlarge timeout to meet most cases.
lp_ticker initialization fails with this issue. Steps for reproducing:
1. System runs in tickless from lp_ticker mode.
2. Arm WDT reset.
3. In next reset cycle, lp_ticker initialization fails (active flag doesn't become active).
When UART interrupt enabled and WDT reset from power-down mode, in the next
cycle, UART interrupt keeps breaking in and cannot block unless via NVIC. To
get around it, we deliberately make up a signal of WDT wake-up from power-down
mode in the start of boot proces when WDT reset is detected.
In no MISO case, skip SPI read so that no more write/read delay contribute to SPI inter-frame delay when data is written successively.
Update targets:
- NUMAKER_PFM_NANO130
- NUMAKER_PFM_NUC472
- NUMAKER_PFM_M453
- NUMAKER_PFM_M487/NUMAKER_IOT_M487
- NU_PFM_M2351_*
- NUMAKER_IOT_M263A
- NUMAKER_M252KG
This bug results from BSP update:
- CRPT: Base address of secure or non-secure crypto module, dependent on partition
- CRPT_S: Base address of secure crypto module
- CRPT_NS: Base address of non-secured crypto module