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

moondew
Posts: 4
Joined: Mon Nov 20, 2017 8:06 pm

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

Postby moondew » Mon Nov 20, 2017 8:18 pm

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
Posts: 870
Joined: Tue Dec 01, 2015 8:37 am

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

Postby ESP_igrr » Wed Nov 22, 2017 5:05 am

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
Posts: 4
Joined: Mon Nov 20, 2017 8:06 pm

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

Postby moondew » Wed Nov 22, 2017 3:20 pm

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
Posts: 870
Joined: Tue Dec 01, 2015 8:37 am

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

Postby ESP_igrr » Thu Nov 23, 2017 6:31 am

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
Posts: 4
Joined: Mon Nov 20, 2017 8:06 pm

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

Postby moondew » Fri Nov 24, 2017 6:24 pm

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
Posts: 4
Joined: Mon Nov 20, 2017 8:06 pm

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

Postby moondew » Mon Nov 27, 2017 8:14 pm

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
Posts: 1214
Joined: Thu Nov 26, 2015 4:08 am

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

Postby ESP_Sprite » Tue Nov 28, 2017 8:28 am

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.

Who is online

Users browsing this forum: No registered users and 10 guests