ESP32-S2FH4 flash specs

cibomahto
Posts: 5
Joined: Mon Aug 09, 2021 7:41 pm

ESP32-S2FH4 flash specs

Postby cibomahto » Wed Aug 25, 2021 2:52 pm

I'm looking for the speed specification for the embedded flash in the ESP32-S2FH4. It doesn't seem to be in the datasheet or technical reference manual, is it available somewhere?

I assumed it was safe to use at 80 MHz, but have seen very intermittent errors when flashing it, so some sort of official guideline would be helpful.

ESP_Sprite
Posts: 9764
Joined: Thu Nov 26, 2015 4:08 am

Re: ESP32-S2FH4 flash specs

Postby ESP_Sprite » Thu Aug 26, 2021 1:35 am

I'd assume the same thing... what specific errors are you getting?

cibomahto
Posts: 5
Joined: Mon Aug 09, 2021 7:41 pm

Re: ESP32-S2FH4 flash specs

Postby cibomahto » Thu Aug 26, 2021 2:20 pm

TLDR: It was likely a layout issue on my board.

I've seen the issue twice now:

Before it happens, I'm able to use the USB-CDC bootloader to flash and run firmware. However, sometimes after leaving a firmware running for some time (2-8 hours), it crashes, and doesn't start again after cycling power. Normally my computer will then not be able to enumerate the USB device, however if I get lucky with the timing then I can connect to it with idf.py monitor, and I see this message in the log (repeated in a loop):

Code: Select all

I (34) boot: ESP-IDF v4.3-1-g1d4dc79ae 2nd stage bootloader
I (35) boot: compile time 15:13:57
I (35) boot: chip revision: 0
I (35) qio_mode: Enabling default flash chip QIO
I (35) boot.esp32s2: SPI Speed      : 80MHz
I (36) boot.esp32s2: SPI Mode       : QIO
I (36) boot.esp32s2: SPI Flash Size : 4MB
I (36) boot: Enabling RNG early entropy source...
E (36) flash_parts: partition 3 invalid magic number 0xefef
E (37) boot: Failed to verify partition table
E (37) boot: load partition table error!

Re-programming the device using the hardware bootloader in DFU mode always works:

Code: Select all

Executing action: dfu-flash
Running make in directory /home/matt/Blinkinlabs-Repos/iced_espresso/examples/CM-2/build
Executing "make -j 6 dfu-flash"...
Command list: dfu-util;-d;303a:2;-D;/home/matt/Blinkinlabs-Repos/iced_espresso/examples/CM-2/build/dfu.bin
dfu-util 0.9

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

Opening DFU capable USB device...
ID 303a:0002
Run-time device DFU version 0110
Claiming USB DFU Runtime Interface...
Determining device status: state = appIDLE, status = 0
Device really in Runtime Mode, send DFU detach request...
Device will detach and reattach...
dfu-util: error detaching
Opening DFU USB Device...
Claiming USB DFU Interface...
Setting Alternate Setting #0 ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 0110
Device returned transfer size 64
Copying data from PC to DFU device
Download        [=========================] 100%       317440 bytes
Download done.
state(2) = dfuIDLE, status(0) = No error condition is present
Done!
Built target dfu-flash
Done
Unfortunately, after a successful flash, the part still didn't boot.

Today I was able to make the issue repeatable. At 80 MHz, setting either of the quad modes (QIO or QOUT) prevented the firmware from booting, but the dual modes (DIO and DOUT) both work. At 20MHz, all options appeared to work.

The issue seems to be with my board design, I had those signals routed over a short distance to an FPGA (as part of an experiment to make a memory-mapped peripheral). The tracks must have been just the right size to make the internal flash communications marginal, and cutting the traces near the ESP pads seems to resolve the issue.

If you run across specs for the internal memories, it would still be good to know :)

ESP_Sprite
Posts: 9764
Joined: Thu Nov 26, 2015 4:08 am

Re: ESP32-S2FH4 flash specs

Postby ESP_Sprite » Fri Aug 27, 2021 1:11 am

Fwiw, you could try to see if you can mess with the drive strength of the pads the flash is connected to... you'll need to do that after the app already is up (or change the bootloader, perhaps) but it may just be enough to give the GPIOs enough oomph to still work even with the FPGA in line.

Who is online

Users browsing this forum: No registered users and 71 guests