Add support for detection of 32-256MB flash chips to the esp stub (OCD-623)

[johnboiles]

Currently the ESP stub does not work for flash chips > 32MB (except for possibly one mysterious 32MB chip with size designator 0x39 🤷). This PR adds support for 32MB, 64MB, 128MB, and 256MB chips. This has been verified as the correct size numbering scheme for Winbond, GigaDevice, and Micron flash chips (see discussion in this PR).

Similar PRs across the Espressif ecosystem:

• Support for 64MB+ mbit flashes (ESPTOOL-500) esptool#769
• Support for Winbond 512 mbit and 1 gbit flash chips (IDFGH-7854) esp-idf#9381
• [flash] Compute size correctly for > 256MBit (IDFGH-8063) esp-idf#9566

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality not to work as expected)
• This change requires a documentation update

How Has This Been Tested?

I've tested this on an ESP32-S3R8 with a 512Mbit (64MB) flash chip.

[gerekon]

Hi @johnboiles

Thanks for the work. But I see that you PR includes code section hex files updates for ESP32-C3 only.
We will pick C-file changes up and generate hex files correctly.

[johnboiles]

If you're able to come up with a change to these files based on this c code please let me know. But I could imagine the compiler could be possibly turn this switch statement into a look up table and put it in .data 🤷

My process was:

• Checkout esp-idf 036bd3eb26, update submodules
• ./install.sh source export.sh
• cd ../openocd-esp32/contrib/loaders/flash/esp
• for dir in esp32 esp32c3 esp32s2 esp32s3; do pushd $dir; make; popd; done
• cd ../esp-idf
• Checkout esp-idf 06b31d487b, update submodules
• ./install.sh source export.sh
• cd ../openocd-esp32/contrib/loaders/flash/esp/esp32c2
• make

[johnboiles]

I was curious so I tried to understand whether the code was reading the .data section of the binary using xtensa-esp32s3-elf-objdump -lSd build/stub_flasher.elf but I haven't quite been able to follow it. I could imagine that last l32i.n possibly loading from the .data section.

[erhankur]

@johnboiles We picked your work as 2 commits (eeb0d52 and 6cd81a6) into the master branch. Please check them and create an issue if you find something. Now, I can close this PR. Thanks for your contribution.