ext_flash_fatfs error 'memspi: no response'

[espmich]

Context

I'm integrating an external SPI flash chip in my custom (ESP32-C3FH4) product for the first time, and having problems.

This MCU has internal flash, so I'm programming (idf.py flash) it with firmware applications and it works well to drive LEDs and read switch inputs.

External flash

I connect an external flash chip to have persistent storage, and I chose the ON Semi CAT25640HU4I-GT3 for its price and availability on LCSC.

Firmware

I build and program the external flash example with ESP-IDF v5.3.1-dirty in the usual way. It builds fine with no errors.

Code: Select all

$ . /path/to/espidf/export.sh
$ cd examples/storage/ext_flash_fatfs
$ idf.py set-target esp32c3
$ idf.py build
$ idf.py flash

Environment

My computer is Ubuntu Linux desktop 24.04 with kernel 6.8.0-49-generic. I connect to my custom (ESP32-C3FH4) product with a USB Type-C cable.

Runtime

When I run idf.py monitor I see:

Code: Select all

Connecting...
Detecting chip type... ESP32-C3
Running idf_monitor in directory /home/myuser/Projects/espidf-531/examples/storage/ext_flash_fatfs
Executing "/home/myuser/.espressif/python_env/idf5.3_py3.12_env/bin/python /home/myuser/Projects/espidf-531/tools/idf_monitor.py -p /dev/ttyACM0 -b 115200 --toolchain-prefix riscv32-esp-elf- --target esp32c3 --revision 3 --decode-panic backtrace /home/myuser/Projects/espidf-531/examples/storage/ext_flash_fatfs/build/ext_flash_fatfs.elf -m '/home/myuser/.espressif/python_env/idf5.3_py3.12_env/bin/python' '/home/myuser/Projects/espidf-531/tools/idf.py'"...
--- esp-idf-monitor 1.5.0 on /dev/ttyACM0 115200
--- Quit: Ctrl+] | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H
ESP-ROM:esp32c3-api1-20210207
Build:Feb  7 2021
rst:0x15 (USB_UART_CHIP_RESET),boot:0xe (SPI_FAST_FLASH_BOOT)
Saved PC:0x4004c50e
--- 0x4004c50e: uart_rx_one_char in ROM

SPIWP:0xee
mode:DIO, clock div:1
load:0x3fcd5820,len:0x1738
load:0x403cc710,len:0xb9c
load:0x403ce710,len:0x2e4c
entry 0x403cc71a
I (24) boot: ESP-IDF v5.3.1-dirty 2nd stage bootloader
I (24) boot: compile time Dec  5 2024 21:14:38
I (25) boot: chip revision: v0.4
I (28) boot.esp32c3: SPI Speed      : 80MHz
I (33) boot.esp32c3: SPI Mode       : DIO
I (37) boot.esp32c3: SPI Flash Size : 2MB
I (42) boot: Enabling RNG early entropy source...
I (47) boot: Partition Table:
I (51) boot: ## Label            Usage          Type ST Offset   Length
I (58) boot:  0 nvs              WiFi data        01 02 00009000 00006000
I (66) boot:  1 phy_init         RF data          01 01 0000f000 00001000
I (73) boot:  2 factory          factory app      00 00 00010000 00100000
I (81) boot: End of partition table
I (85) esp_image: segment 0: paddr=00010020 vaddr=3c030020 size=0b314h ( 45844) map
I (101) esp_image: segment 1: paddr=0001b33c vaddr=3fc8c600 size=01554h (  5460) load
I (103) esp_image: segment 2: paddr=0001c898 vaddr=40380000 size=03780h ( 14208) load
I (113) esp_image: segment 3: paddr=00020020 vaddr=42000020 size=262e8h (156392) map
I (143) esp_image: segment 4: paddr=00046310 vaddr=40383780 size=08d1ch ( 36124) load
I (154) boot: Loaded app from partition at offset 0x10000
I (154) boot: Disabling RNG early entropy source...
I (166) cpu_start: Unicore app
I (174) cpu_start: Pro cpu start user code
I (174) cpu_start: cpu freq: 160000000 Hz
I (174) app_init: Application information:
I (177) app_init: Project name:     ext_flash_fatfs
I (183) app_init: App version:      v5.3.1-dirty
I (188) app_init: Compile time:     Dec  5 2024 21:14:31
I (194) app_init: ELF file SHA256:  7c84b2c43...
I (199) app_init: ESP-IDF:          v5.3.1-dirty
I (205) efuse_init: Min chip rev:     v0.3
I (209) efuse_init: Max chip rev:     v1.99 
I (214) efuse_init: Chip rev:         v0.4
I (219) heap_init: Initializing. RAM available for dynamic allocation:
I (226) heap_init: At 3FC8EAB0 len 00031550 (197 KiB): RAM
I (233) heap_init: At 3FCC0000 len 0001C710 (113 KiB): Retention RAM
I (240) heap_init: At 3FCDC710 len 00002950 (10 KiB): Retention RAM
I (247) heap_init: At 50000200 len 00001DE8 (7 KiB): RTCRAM
I (254) spi_flash: detected chip: generic
I (257) spi_flash: flash io: dio
W (261) spi_flash: Detected size(4096k) larger than the size in the binary image header(2048k). Using the size in the binary image header.
I (275) sleep: Configure to isolate all GPIO pins in sleep state
I (281) sleep: Enable automatic switching of GPIO sleep configuration
I (289) main_task: Started on CPU0
I (289) main_task: Calling app_main()
I (289) example: Initializing external SPI Flash
I (299) example: Pin assignments:
I (299) example: MOSI:  7   MISO:  5   SCLK:  6   CS:  4
I (309) example: DMA CHANNEL: 3
E (309) memspi: no response

E (319) example: Failed to initialize external Flash: ESP_ERR_INVALID_RESPONSE (0x108)
I (319) main_task: Returned from app_main()

Problem

I expect the output to appear with no errors or faliures. Instead I see two (E 309 and E 319) errors.

Modifications

Of course, I first modified the SPI pins to suit my own product:

main/ext_flash_fatfs_example_main.c.orig main/ext_flash_fatfs_example_main.c
43,48c43,48
< #define PIN_MOSI SPI2_IOMUX_PIN_NUM_MOSI
< #define PIN_MISO SPI2_IOMUX_PIN_NUM_MISO
< #define PIN_CLK SPI2_IOMUX_PIN_NUM_CLK
< #define PIN_CS SPI2_IOMUX_PIN_NUM_CS
< #define PIN_WP SPI2_IOMUX_PIN_NUM_WP
< #define PIN_HD SPI2_IOMUX_PIN_NUM_HD
---
> #define PIN_MOSI 7
> #define PIN_MISO 5
> #define PIN_CLK 6
> #define PIN_CS 4
> #define PIN_WP 8
> #define PIN_HD 10

Questions

When the MCU responds E (309) memspi: no response does this mean the application failed?

Is it failing because the external flash chip I use is 10 (or 20) MHz instead of 40 MHz?

Is it failing because my external flash chip WP and HD pins are permanently connected to 3V3?

Is it failing because I set the PIN_WP and PIN_HD in the example firmware to unused GPIOs 8 and 10?

Is it failing because the ESP-IDF flash chip driver does not support my external flash chip at all?

If I use the ESP-IDF example custom_flash_driver would it start working? I don't want to do extra work.

If I replace my chosen external flash chip model with another one, will it work without writing a custom driver?

Are the manufacturers EON, ISSI, GD, Macronix, Winbond, Boya well supported by the standard ESP-IDF flash driver?

What are a few recommendations of inexpensive (just some kilobytes) of external flash chips (DFN or QFN) that work well?

Thank you!

[espmich]

I believe the storage chip I chose is not a real flash part, but rather a EEPROM that is not supported by the ESP-IDF flash storage API.

Unfortunately, the peripherals/spi_master/hd_eeprom example also fails, so I'm trying to understand that now.

Code: Select all

I (159) cpu_start: Unicore app
I (167) cpu_start: Pro cpu start user code
I (167) cpu_start: cpu freq: 160000000 Hz
I (167) app_init: Application information:
I (170) app_init: Project name:     spi_eeprom
I (175) app_init: App version:      v5.3.1-dirty
I (181) app_init: Compile time:     Dec  6 2024 00:18:27
I (187) app_init: ELF file SHA256:  74e4d7996...
I (192) app_init: ESP-IDF:          v5.3.1-dirty
I (197) efuse_init: Min chip rev:     v0.3
I (202) efuse_init: Max chip rev:     v1.99 
I (207) efuse_init: Chip rev:         v0.4
I (212) heap_init: Initializing. RAM available for dynamic allocation:
I (219) heap_init: At 3FC8FD30 len 000302D0 (192 KiB): RAM
I (225) heap_init: At 3FCC0000 len 0001C710 (113 KiB): Retention RAM
I (232) heap_init: At 3FCDC710 len 00002950 (10 KiB): Retention RAM
I (239) heap_init: At 50000200 len 00001DE8 (7 KiB): RTCRAM
I (246) spi_flash: detected chip: generic
I (250) spi_flash: flash io: dio
W (254) spi_flash: Detected size(4096k) larger than the size in the binary image header(2048k). Using the size in the binary image header.
I (267) sleep: Configure to isolate all GPIO pins in sleep state
I (274) sleep: Enable automatic switching of GPIO sleep configuration
I (281) main_task: Started on CPU0
I (281) main_task: Calling app_main()
I (281) main: Initializing bus SPI2...
I (291) main: Initialising okay device...
I (291) gpio: GPIO[4]| InputEn: 0| OutputEn: 1| OpenDrain: 0| Pullup: 0| Pulldown: 0| Intr:0 
I (301) main: Write: Hallo Welt 1A!
I (311) main: Read: ���������������
I (311) main: Example finished.

This only works with the ON Semi CAT25640HU4I when I set (idf.py menuconfig) the example configuration to disable interrupts to the eeprom.

[Sprite]

To sidestep the entire issue: The internal flash already is divided into partitions (one for the bootloader, one for the app, one for NVS, etc). You could simply add your own partition and save whatever you want there, and it won't overwrite the firmware. Also, dependent on your use case, I'd suggest looking into NVS and SPIFFS; if you need to save only a few kilobytes, those may be applicable as they already handle atomicity and wear leveling for you.

[espmich]

Yes I think that ESP_Sprite is correct about preferring NVS in most cases.

In this case, a number of reasons exist to make me prefer designing with a real EEPROM and using SPI.

So I implemented a SPI Master driver for the ON Semi CAT25 chip I'm using. The driver works well.

Now it's time to replace the ON Semi with a Microchip EEPROM, as it seems the ON Semi parts are not well supported by the manufacturer.

If you're curious, one of the reasons for using a real EEPROM is portability. If you want to (re)use knowledge and standard methods across different MCU types (Renesas, Microchip, ST, Espressif, Atmel) it's not worth relearning all the NVS methods of the different controllers.

[Sprite]

If you're curious, one of the reasons for using a real EEPROM is portability. If you want to (re)use knowledge and standard methods across different MCU types (Renesas, Microchip, ST, Espressif, Atmel) it's not worth relearning all the NVS methods of the different controllers.

That is fair. I'd probably save me the BOM cost and write an universal abstraction layer over the various NVS implementations, but adding an extra chip also is a valid choice.

[espmich]

When using external SPI EEPROM, another (besides extra part to pay for) disadvantage is that the part cannot be programmed during idf.py flash.

Storage provisioning

It seems that such autoprogramming is only possible in examples/fatfsgen and examples/spiffsgen because of using NVS and a partition on the same flash that gets programmed with bootload and instruction code.

Question

Is there an easy way to program a I2C or SPI EEPROM, during the idf.py flash operation?

[Sprite]

I know that esptool.py has the option to program a flash chip connected to given GPIOs. I don't know if idf.py has support for that as well, though.