Floating the Flash SPI pins to allow a 2nd processor to access flash memory

[moondew]

Hi,

We have a board were we need to force the ESP32 to float it's SPI pins to the flash memory to allow a second processor to read. Once it has been read the ESP32 reboots. It seems simple enough, but have so far been unsuccessful. It appears the ESP32 is still driving the SPI output pins.

The second processor is able to read the ESP32 flash if we reboot the ESP32 with the flashing jumper inserted to prevent the ESP32 from booting.

Here is the latest attempt.

disable_interrupts_caches_and_other_cpu();

gpio_config_t config;

config.pin_bit_mask = GPIO_SEL_6 | GPIO_SEL_7 | GPIO_SEL_8 | GPIO_SEL_9 | GPIO_SEL_10 | GPIO_SEL_11;
config.mode = GPIO_MODE_INPUT;
config.pull_up_en = GPIO_PULLUP_DISABLE;
config.pull_down_en = GPIO_PULLDOWN_DISABLE;
config.intr_type = GPIO_INTR_DISABLE;

gpio_config(&config);

// loop here waiting for a specific gpio pin to change state, then reboot

Is there something else we need to disable as well?

Thanks

[ESP_igrr]

ESP32 executes most of the code from flash, so disabling access to flash will immediately cause ESP32 to fail fetching the next instruction, unless the code to disable and re-enable SPI flash pins is placed into IRAM, and cache is disabled.
Also the code you have attached doesn't re-configure SPI flash pins back to their original state.

[moondew]

Note that first we call disable_interrupts_caches_and_other_cpu().

At the end we // loop here waiting for a specific gpio pin to change state, then reboot.

These two things work fine, it is just that the SPI bus is still driven.

[ESP_igrr]

Oh, sorry, i misunderstood the "Once it has been read the ESP32 reboots" phrase. I thought that rebooting was the observed (undesirable) behavior.

Looking at GPIO driver code, it seems that it does all things necessary to configure pins as GPIOs. Which esp-idf version are you using?

Also note that GPIO driver itself is not in IRAM, so there is a chance that an exception will happen when you call gpio_config function.
The exception may also not happen if this function was called previously and its code is still present in cache.

Can you add some debugging output into this function to verify that ESP32 is indeed waiting for GPIO to be toggled?
Something like ets_printf(DRAM_STR("format string")); should work even with cache disabled.

[moondew]

Except once all the interrupts and caching has been disabled, it is not possible to display debugging output.

At this point we are looking at simply having the second processor directly hold the ESP32 in reset while it is reading the flash.

[moondew]

Unfortunately, holding the ESP32 in reset does not allow access to the flash memory from a second processor.

It looks like we will have to add a second flash memory part on one of the application SPI controller. Not a big deal except for the time and expense of turning the board.

[ESP_Sprite]

Well, you could still go down the route ESP_igrr indicated? With the DRAM_ATTR combined with ets_printf you should be able to print debug output, even when the cache and interrupts are off.