SPI settings - "Serial flasher config" (and the big picture)

[vinci1989]

Hello

Can someone explain a few things to me about the SPI settings? I'm trying to understand how the "Serial flasher config" settings relate to idf.py, the *-flash_args files generated during a build and the SPI peripheral settings ultimately used in the chip.

So, for starters, do the "Serial flasher config" settings actually end up in a binary? I guess yes, but how? Do those settings somehow get written into the bootloader?
If those settings get placed in the bootloader, why do they also get written to the *-flash_args files? What does idf.py do with those settings when writing a binary to the chip via serial?
Espressif also does offer a serial-flasher C library. If those *-flash_args settings are somehow relevant when writing binary data to the chip, why does the library not offer any SPI settings functions?
In my current project for an ESP32S3 I've enabled octal flash and set the SPI mode to OPI. Yet all the *-flash_args file generated by ESP-IDF contain

Code: Select all

--flash_mode dout

. Is this a bug?

I'm sorry if some of those questions are somewhat stupid...

[ESP_Sprite]

This is partially from memory, so please double-check if any of this is actually true if you want to build on it. With that said:

Generally, the config for the SPI flash chips is encoded into the first few bytes of the application image (the .bin files) that gets put into flash. This goes for both the 2nd bootloader app image as well as any user app image you put into flash. This is generated when the application image is generated from the linked elf image; see the 'elf2image' option of esptool.py for more information.

The ROM bootloader will load the first few bytes of the 2nd bootloader app image, then reconfigure the flash memory interface in the way those header bytes indicate. Note that while the application app image also has these configuration bytes, I'm not sure if anything honours them; they may simply be there to keep the app image format the same.

(As a bit of legacy, esptool.py also has the option to change these configuration bytes on-the-fly while flashing the chip. I'm not sure if that is still used as it interferes with some hashing methods that we also use. serial-flasher never had that on-the-fly rewrite option, so you need to properly set the SPI flash options while building the application images.)

Octal flash is handled a bit differently. As octal flash isn't really that mature yet, we haven't put the code to handle that in ROM (and run the risk of incompatibility if the octal flash protocol that is de-facto used changes). Instead, we use the fact that each octal flash chip also supports the very basic dout mode in order to load the 2nd bootloader and (the part that needs to be loaded into RAM of the) application image. As soon as those are loaded, we switch to OPI; as this happens in code that is in flash, we can always upgrade it later.

Hope that helps.

[vinci1989]

Thank you very much for this in-depth explanation.

Your reply could easily go into the docs... Currently you'd have to piece that kind of information together from 3x different sources (esptool, SPI and bootloader).

Note that while the application app image also has these configuration bytes, I'm not sure if anything honours them; they may simply be there to keep the app image format the same.

Apparently those settings are used yes. The latest docs say that:

When the Second Stage Bootloader then runs, it will reconfigure the flash using values read from the currently selected app binary’s header (and NOT from the Second Stage Bootloader header). This allows an OTA update to change the SPI flash settings in use.

https://docs.espressif.com/projects/esp ... oader.html