The ones that I think should be handled in the hal:
[ ] 3.3 When the CPU accesses peripherals and writes a single
address repeatedly, some writes may be lost. (rev 0 only)
[ ] 3.5 The CPU crashes when the clock frequency switches directly
from 240 MHz to 80/160 MHz. (rev 0 only)
[x] 3.6 GPIO pull-up and pull-down resistors for pads with both GPIO
and RTC_GPIO functionality can only be controlled via
RTC_GPIO registers. (rev0, rev1 and rev3) => done in #36
[ ] 3.10. When each CPU reads certain different address spaces
simultaneously, a read error can occur. (rev0 and rev 3)
[ ] 3.15. The ESP32 chip may have a live lock under certain conditions
that will cause interrupt watchdog issue. (rev 3 only)
[ ] 3.16. There are limitations to the CPU access to 0x3FF0_0000 ~
0x3FF1_EFFF and 0x3FF4_0000 ~ 0x3FF7_FFFF address
spaces.
[ ] 3.17. UART fifo_cnt is inconsistent with FIFO pointer.
[ ] 3.18. CPU has limitations when accessing peripherals in chips. (summary of rev 3.3, 3.10 and 3.16)
Ones that need attention in future hal drivers:
[ ] 3.7 Audio PLL frequency range is limited. (rev 0 only)
[ ] 3.12 When the LEDC is in decremental fade mode, a duty overflow
error can occur.
[ ] 3.13. ESP32 CAN Errata
The ones that should be handled by the user:
[ ] 3.1 A spurious watchdog reset occurs when ESP32 is powered up
or wakes up from Deep-sleep. (rev 0 only) handle in startup routine from deep-sleep
[x] 3.4 The Brown-out Reset (BOR) function does not work. The
system fails to boot up after BOR. (rev 0 only) => no fix possible
[ ] 3.8 Due to the flash start-up time, a spurious watchdog reset
occurs when ESP32 is powered up or wakes up from Deepsleep. (rev 0 and rev1)
[ ] 3.11. When certain RTC peripherals are powered on, the inputs of
GPIO36 and GPIO39 will be pulled down for approximately 80
ns.
[ ] 3.14. The ESP32 GPIO peripheral may not trigger interrupts
correctly. => user needs to avoid multiple edge triggered GPIO interrupts. Should document in gpio module.
The ones that should be handled in the compiler:
[ ] 3.2 When the CPU accesses external SRAM through cache, under
certain conditions read and write errors occur.
[ ] 3.9. When the CPU accesses the external SRAM in a certain
sequence, read & write errors can occur. (rev 0 and rev 1)
ESP32 has several errata (ESP32 eco and workarounds for bugs in esp32). We should consider implementing workarounds.
The ones that I think should be handled in the hal:
Ones that need attention in future hal drivers:
The ones that should be handled by the user:
The ones that should be handled in the compiler: