- CRC for core dump flash partition config
- Tasks with corrupted TCBs are skipped
- Assertions to check that nothing is written beyond core dump flash partition
- Implements application tracing module which allows to send arbitrary
data to host over JTAG. This feature is useful for analyzing
program modules behavior, dumping run-time application data etc.
- Implements printf-like logging functions on top of apptrace module.
This feature is a kind of semihosted printf functionality with lower
overhead and impact on system behaviour as compared to standard printf.
The following issues mentioned during MR!341 review were fixed:
1) Core dump test application description
2) Usage of CONFIG_ESP32_ENABLE_COREDUMP_TO_FLASH and CONFIG_ESP32_ENABLE_COREDUMP_TO_UART
3) FLASH_GUARD_START macro usage is fixed in flash API
4) Core dump module logging facility
5) cache util functions doc updated
6) interactive delay before print core dump to uart
7) core dump partion support in build system
1) PS is fixed up to allow GDB backtrace to work properly
2) MR!341 discussion: in core dump module: esp_panicPutXXX was replaced by ets_printf.
3) MR!341 discussion: core dump flash magic number was changed.
4) MR!341 discussion: SPI flash access API was redesigned to allow flexible critical section management.
5) test app for core dump feature was added
6) fixed base64 file reading issues on Windows platform
7) now raw bin core file is deleted upon core loader failure by epscoredump.py
Complimentary changes:
1) Partition table definitions files with core dump partition
2) Special sub-type for core dump partition
3) Special version of spi_flash_xxx
4) espcoredump.py is script to get core dump from flash and print useful info
5) FreeRTOS API was extended to get tasks snapshots
On Xtensa windowed ABI backtrace is easy to do, and it's immensely
useful for debugging, so - do it by default.
We try to be careful and not deref bogus pointers while walking the
frames.
Example output (from debugging espressif/esp-idf#133):
Backtrace: 0x1:0x3ffc51e0 0x400e9dfa:0x3ffc5210 0x400e9ebc:0x3ffc5230 0x400ec487:0x3ffc5260
With just addr2line utility from binutils, this already pinpoints the
location of the crash.
