Open m-sawant opened 2 years ago
One more observation is the device does not come out of the Cache_Flush(0); Execution and breaks while trying to stall othercpu(), Can anyone answer why the esp32 doesn't come out of the following loop from the dport_access.c file, I am not able to find anything in the user manual. while (!dport_access_start[cpu_id]) {};
Environment
git describe --tags
to find it): v4.3.1-3-gc5f29dd524xtensa-esp32-elf-gcc --version
to find it): xtensa-esp32-elf-gcc (crosstool-NG esp-2021r1) 8.4.0Problem Description
IF app_main() task running with the default priority=1, then NO partition API works and the crash appears at Cache_Flush(0); in the file flash_mmap.c -> spi_flash_mmap_pages() If WDT is enabled then WDT resets the device with reset reason as TG1WDT_SYS_RESET and repeats this in a continuous reset loop
Expected Behavior
The esp32 should not get crash while doing Cache flush
Actual Behavior
The device goes in the hanged mode or resest if WDT enabled when Cache_Flush is called while calling partition API from App layer
Code to reproduce this issue
Simple code in blinky app,just before blinky app's while 1 loop starts, added partition usage API's. This will work in the espidf scenario, However, I am using the Bazel build system to simulate exactly same steps as Cmake does, Able to debug and pinpoint the issue at the file flash_mmap.c ----> spi_flash_mmap_pages() --> Cache_Flush() Also in the debug window nothing can be seen about the esp internals, debugging control goes missing, Program counter doesn't show up in the call stack
Debug Logs
Other items if possible
partition-table-.csv sdkconfig.txt