ESP32-S3 Instruction Set

[gschorcht]

Hi,

I get a StoreProhibitedCause exception in ESP-IDF function spi_timing_config_set_psram_clock for an ESP32-S3 in following instruction:

Code: Select all

ee.stf.64.xp    f2, f0, a2, a0

It seems to be an extended instruction which is not documented in "Xtensa Instruction Set Architecture (ISA) Reference Manual".

Where can I find the documentation for this instruction?

Regards
Gunar

[ESP_Sprite]

The instructions will end up in the TRM eventually, but it's a very big chapter and unfortunately not ready for publishing yet... Are you sure that that is an actual instruction, and not your disassembler stumbling on something? 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.

[gschorcht]

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.

[ESP_Sprite]

Yeah, the dump of memory before the corruption likely loads that bit of code into the cache while the flash interface is still working.

Can you tell a bit more about the hardware you're doing this on (devboard or custom hw, ESP32 version, what flash/psram you're using) and what ESP-IDF this is? It feels like this is some glitch in setting the clock we need to work around somehow.

[gschorcht]

Can you tell a bit more about the hardware you're doing this on (devboard or custom hw, ESP32 version, what flash/psram you're using) and what ESP-IDF this is? It feels like this is some glitch in setting the clock we need to work around somehow.

I'm using a ESP32-S3-DEVKITC-1-N8R2-ND board with ESP-IDF release/v4.4 commit eb3797dc3ffebd9eaf873a01df63aed89fad58b6 and the default configuration:

Code: Select all

#define CONFIG_ESP32S3_SPIRAM_SUPPORT           1
#define CONFIG_SPIRAM_TYPE_AUTO                 1
#define CONFIG_SPIRAM_SIZE                      -1
#define CONFIG_SPIRAM_SPEED_40M                 1
#define CONFIG_SPIRAM                           1
#define CONFIG_SPIRAM_BOOT_INIT                 1
#define CONFIG_SPIRAM_MEMTEST                   1
#define CONFIG_SPIRAM_MALLOC_ALWAYSINTERNAL     16384
#define CONFIG_SPIRAM_MALLOC_RESERVE_INTERNAL   32768
#define CONFIG_SPIRAM_MODE_QUAD                 1
#define CONFIG_SPIRAM_SUPPORT                   CONFIG_ESP32S3_SPIRAM_SUPPORT
#define CONFIG_DEFAULT_PSRAM_CLK_IO             30
#define CONFIG_DEFAULT_PSRAM_CS_IO              26

[ESP_Sprite]

That looks decent... Wondering if it's because something in 4.4. Would it be possible for you to switch to the master branch of esp-idf and see if that fixes it?

Possibly something else to try is to change both the speed of the flash (it's in menuconfig under serial flasher config, iirc) as well as the speed of the PSRAM to 80MHz.

[gschorcht]

Possibly something else to try is to change both the speed of the flash (it's in menuconfig under serial flasher config, iirc) as well as the speed of the PSRAM to 80MHz.

Solved. Thanks for that hint. The reason was that the bootloader was compiled with flash frequency 40 MHz and not with 80 MHz which obviously led to problems during startup procedure when the clocks are configured.

[ESP_Sprite]

Can you be a bit more precise in what happened? You say you were running flash at 40MHz, but your sdkconfig also says your psram runs at 40MHz... that should work imo. Was there a mismatch somewhere else? (Asking because I'm wondering if we should catch this error so we don't crash on some obscure instruction.)