xtensa linker throws warning
dangerous relocation: windowed longcall crosses 1GB boundary; return may fail
create separate function to call function by pointer to avoid warnings
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
Updated S3 to use PMS protection for writing to flash through cache. This means we get
a panic quicker for this illegal behavior than we did before, making the source of the error
easier to track down.
Before this change _invalid_pc_placeholder pointed to address of _init
function from crti.o
This made GDB input a bit confusing:
0x40080400 in _init ()
(gdb) bt
#0 0x40080400 in _init ()
#1 0x400e519a in test_instr_fetch_prohibited () at /home/alex/git/esp-idf/tools/test_apps/system/panic/main/test_panic.c:271
#2 0x400d89a7 in app_main () at /home/alex/git/esp-idf/tools/test_apps/system/panic/main/test_app_main.c:116
#3 0x400e5f22 in main_task (args=0x0) at /home/alex/git/esp-idf/components/freertos/app_startup.c:208
#4 0x400895a8 in vPortTaskWrapper (pxCode=0x400e5eb0 <main_task>, pvParameters=0x0) at /home/alex/git/esp-idf/components/freertos/FreeRTOS-Kernel/portable/xtensa/port.c:139
After the change GDB prints output that contains a hint:
_invalid_pc_placeholder () at /home/alex/git/esp-idf/components/xtensa/xtensa_vectors.S:2235
2235 UNREACHABLE_INSTRUCTION_CHECK_PREVIOUS_FRAMES
(gdb) bt
#0 _invalid_pc_placeholder () at /home/alex/git/esp-idf/components/xtensa/xtensa_vectors.S:2235
#1 0x400e519e in test_instr_fetch_prohibited () at /home/alex/git/esp-idf/tools/test_apps/system/panic/main/test_panic.c:271
#2 0x400d89ab in app_main () at /home/alex/git/esp-idf/tools/test_apps/system/panic/main/test_app_main.c:116
#3 0x400e5f26 in main_task (args=0x0) at /home/alex/git/esp-idf/components/freertos/app_startup.c:208
#4 0x400895a8 in vPortTaskWrapper (pxCode=0x400e5eb4 <main_task>, pvParameters=0x0) at /home/alex/git/esp-idf/components/freertos/FreeRTOS-Kernel/portable/xtensa/port.c:139
- As the PMA entry that made some memory regions cacheable was
assigned the highest priority, some intermediate inaccessible
memory regions bypassed protection.
- Added tests for the same
- Verified that even after changing the priority of the PMA entry,
a write operation at SOC_IRAM_LOW + 0x40 (a random RAM cached address)
still needs the same number (29) of CPU cycles.
