ESP_Sprite wrote: ↑Wed May 11, 2022 7:05 am
Given the fact it's in a function to do with the psram clock and the psram is on the same bus as the flash, I'm wondering if the actual issue is not that something mis-configures that bus, corrupting flash reads, and fetching the next instructions in that function result in garbage.
Indeed, it seems to be a cache problem. When I break the execution in debugger after the call of
rom_config_instruction_cache_mode in
call_start_cpu0 and dump the memory at the address of function
spi_timing_config_set_psram_clock before it is called, the according disassembled code is
Code: Select all
0x42002894 <spi_timing_config_set_psram_clock> entry a1, 32
0x42002897 <spi_timing_config_set_psram_clock+3> l32r a8, 0x42002818
0x4200289a <spi_timing_config_set_psram_clock+6> extui a2, a2, 0, 8
...
and the application works as expected. Without dumping the memory before, the disassembler in debugger shows
Code: Select all
0x42002894 <spi_timing_config_set_psram_clock> entry a1, 32
0x42002897 <spi_timing_config_set_psram_clock+3> l32r a8, 0x42002818
0x4200289a <spi_timing_config_set_psram_clock+6> ee.stf.64.xp f2, f0, a2, a0
...
and the application crashes at address
0x4200289a. So it seems that the cache content is only correct after the second read of address
0x4200289a. This is really strange.