This commit updates the following:
- Updates the panic handler to use only the RTC WDT to reset the system.
- Refactors some of the panic handler code.
- Updates Bluetooth files where in they now feed the WDTs instead of
reconfiguring them.
- Removes some unnecessary configuration of WDTs from various files.
- Added a unit test to verify that the system does not lock up when the
panic handler is stuck.
- Updates the memprot unit tests to work with the refactored panic
handler.
Closes https://github.com/espressif/esp-idf/issues/15166
Closes https://github.com/espressif/esp-idf/issues/15018
Closes https://github.com/espressif/esp-idf/issues/10110
- Add support for esp32s2, esp32c3 and esp32c2 for the `memprot`-related tests
- Preliminary support for esp32s3 has also been added,
the test app will be enabled for esp32s3 later when
the memprot-related issues are fixed.
- Override panic handler to dump the violation intr status
- Dump the `memprot` violation registers before calling the
real panic handler
- Handle `Illegal Instruction` exception in case of memprot permission violation
* In esp32c3 with `memprot` enabled, if we try to execute arbitrary code
from RTC_FAST_MEM we get an `Illegal Instruction` exception from the panic
handler rather than a `Memory Protection Fault`.
* This is because the Illegal Instruction interrupt occurs earlier than the
memory protection interrupt due to a higher interrupt latency.
pytest_panic used to do 'from conftest import PanicTestDut'. This
stopped working when another conftest.py file was added in
tools/test_build_system/conftest.py.
In this case we can't rename conftest.py since both are necessary
for pytest to install the hooks in the respective test cases.
Fix by moving PanicTestDut into a separate module, then importing
it from there.
Theory is that on the runner, in rare cases, gdb may need more than
1 second to load and start responding to commands.
However it's possible these timeouts are due to some other problem
(like gdb failing)
Small quality-of-life improvement, make it easier to run specific
test cases, when debugging the tests locally.
Take the optional list of test cases to run from the command line.
InstrFetchProhibited usually occurs because of a jump to an invalid
pointer. In this case, PC in the exception frame is the address of
the jump destination. 'esp_ptr_executable' check in print_backtrace
function recognizes the first frame as invalid, and the backtrace is
interrupted. This prevents the user from finding the location where
the invalid pointer is dereferenced.
Bypass the 'esp_ptr_executable' check if the exception cause is
InstrFetchProhibited. Update the test case to no longer ignore this
issue.
