Custom SPI flash configuration (--spi-connection) does not work properly (ESPTOOL-94)

[OtherCrashOverride]

No matter what CS line is given as a parameter, it appears to be ignored in the following example:
esptool.py --chip esp32 flash_id --spi-connection 6,7,8,9,33

The above will always use the internal flash.

[edit]
The issue does not occur when using "--no-stub".

[projectgus]

It may be a little while before I get to verify this. Do you still see this bug even when the CS pin is set to a lower value? Possible there's a bug translating pin numbers >31.

[OtherCrashOverride]

I tested 16, 17, 19, and 33. All resulted in the internal flash being used.

[Buckler89]

Hi,
I'm using esptool.py v2.2.1.
I have the same problem. Moreover not only the CS pin appears to be ignored but also all other except for the Q PIN. My external 16MB flash is connected to
CLK = GPIO 6
Q = GPIO 7
D = GPIO 8
HD = GPIO 9
CS = GPIO 5 (11 is the default 4MB flash)

I have tried change all the pin ( also randomly) and if I keep the Q = 7 I get the output related to the standard 4MB flash:

esptool.py --port /dev/ttyUSB1 flash_id --spi-connection <any>,7,<any>,<any>,<any>

Detecting chip type... ESP32
Chip is ESP32D0WDQ6 (revision 1)
Uploading stub...
Running stub...
Stub running...
Configuring SPI flash mode...
Manufacturer: c8
Device: 4016
Detected flash size: 4MB

while unknow data if Q != 7 ( independently of the value of the other pins):

esptool.py --port /dev/ttyUSB1 flash_id --spi-connection <any>,<any>,<any>,<any>,<any>

Detecting chip type... ESP32
Chip is ESP32D0WDQ6 (revision 1)
Uploading stub...
Running stub...
Stub running...
Configuring SPI flash mode...
Manufacturer: ff
Device: ffff
Detected flash size: Unknown

does anyone have any updates on this?

[negativekelvin]

Bad prototype?

esptool/flasher_stub/rom_functions.h

Line 47 in b8f6793

void spi_flash_attach();

[Buckler89]

@negativekelvin What do you mean?

[negativekelvin]

It should be void spi_flash_attach(uint32_t ishspi, bool legacy); but I don't know if that is enough to cause the failure due to the assembler/linker not having enough information about the calling convention. It is the only reason I could see that the call might succeed from rom but fail from stub.

[vccground]

Doesn't work for me too, I tried 6,7,8,9,23 but the tool ignores and uses the internal flash.

Is this fixed, any updates?

[SunilDullolli]

Any updates?

My Issue:
I am able to do "esptool.py --no-stub --port COM17 --after no_reset flash_id --spi-connection 18,19,23,21,5" and I get this (It sees the correct 16MB external flash):
esptool.py v2.6
Serial port COM17
Connecting....
Detecting chip type... ESP32
Chip is ESP32D0WDQ6 (revision 1)
Features: WiFi, BT, Dual Core, Coding Scheme None
MAC: 30:ae:a4:47:4d:7c
Configuring SPI flash mode...
Manufacturer: ef
Device: 4018
Detected flash size: 16MB
Staying in bootloader.

and when I try to load files to external flash, it again defaults to on-board 4MB flash.

$ esptool.py --no-stub --port COM17 write_flash 0x10000 file.txt
esptool.py v2.6
Serial port COM17
Connecting.....
Detecting chip type... ESP32
Chip is ESP32D0WDQ6 (revision 1)
Features: WiFi, BT, Dual Core, Coding Scheme None
MAC: 30:ae:a4:47:4d:7c
Enabling default SPI flash mode...
Configuring flash size...
Auto-detected Flash size: 4MB
Erasing flash...
Took 0.02s to erase flash block
Wrote 2048 bytes at 0x00010000 in 0.2 seconds (81.9 kbit/s)...
Hash of data verified.

Leaving...
Hard resetting via RTS pin...

It looks to me like it is the same issue that everyone here is facing.. or am I missing something else?

Thanks.

[negativekelvin]

Use --spi-connection in all your commands not just the first one

[SunilDullolli]

Thank you @negativekelvin, it now works as intended.

[radimkarnis]

I’m closing this issue because it has been inactive for a few months and it seems like it's not relevant anymore. Please reopen if further discussion is needed.

[negativekelvin]

@radimkarnis was this fixed in the stub loader?

[radimkarnis]

Hello, after taking a second look I decided to reopen this issue. The decision to close it was hasty and based on an unrelated solution mentioned by @SunilDullolli.

[FancyQian]

Hi Team, any update for this issue?