board: Huidu Hd wf2/wf4 flash dio mode

[vortigont]

for some strange reason this board's flash needs "BOARD_HAS_PSRAM" flag otherwise it starts in some wrong (RO?) mode were both NVRAM and LittleFS mount fails

[Jason2866]

Does the board has PSRAM? If not there is something wrong with the boards.json
Adding random PSRAM flag is not the solution.

[vortigont]

It does not have PSRAM chip. It has 8MiB flash chip cfeon qh64a and the only way I was able to make it work properly is to use BOARD_HAS_PSRAM build flag.
Even tried to swap the flash chip and solder winbond 16MiB instead - it works pretty fine with/without BOARD_HAS_PSRAM flag. Confirmed with three different boards, so it's not a bad piece.
Also tried to build and flash via arduino cli tool with a custom board definition (PR espressif/arduino-esp32#10779) - same story, it starts RO without this flag.
I've killed a day to figure this out and out of ideas for now on how configure it properly, so any hints would be appreciated.

[TD-er]

This is an ESP32-S3, right?
(I base this on the linked PR board definition)

Since the S3 does have a rather nasty track record on aweful strict flash/PSRAM configuraton demands, could it be that simply setting the PSRAM does also change some other mode for flash interactions or simply adds enough wait states when interacting with the flash?

[Jason2866]

The issues you see with LittleFS and NVRAM are typical for wrong flash mode.
As @TD-er already mentioned there are many "chances" to do it not correctly for the S3
So which S3 type is exactly assembled?

[vortigont]

this is what I can get out of it

Detecting chip type... ESP32-S3
Chip is ESP32-S3 (revision v0.2)
Features: WiFi, BLE
Crystal is 40MHz
MAC: 30:30:f9:xx:xx:xx
Uploading stub...
Running stub...
Stub running...
Manufacturer: 1c
Device: 7017
Detected flash size: 8MB
Flash type set in eFuse: quad (4 data lines)

Chip label has Espressif's logo and ESP32-S3 label along with 302023 and UC00MAG212, not sure what it means.

There is definitely something with SPI NOR flash chip since replacing the flash resolves the issue. Either some internal command or, maybe, WP signal to the chip is being set wrong.
I could blame some crappy piece that I have, but I confirmed the same behavior with other people who got same board (and similar model WF4) - all behave similar.
Also similar reported here and here

[TD-er]

Hmm the fact you mention it is NOR flash instead of NAND made me wonder what exactly is the difference here.
One source: https://www.embedded.com/flash-101-nand-flash-vs-nor-flash

This site mentions that NAND flash is typically faster than NOR flash. Especially when erasing data.
So it might be a timing issue?

Or am I mistaken here and is all flash for ESP-like board just NOR flash?
Then why is the device type starting with a 7 instead of the '4' we usually see?

[Jason2866]

Flash mode QIO has to be supported in specific vendor source code in IDF.
If this is not working correctly flash writing and reading fails now and than.
Using mode DIO instead of QIO should work. The for sure always working mode is DOUT.
Replacing solves the issue since the used flash is from a (quality) vendor which is software supported in IDF.

Either replace flash (as you did already) or use flash mode DIO / DOUT.
EDIT: This looks like my thoughts are correct mrcodetastic/ESP32-HUB75-MatrixPanel-DMA#667 (reply in thread)

[Jason2866]

If you tried WLED, that's highly problematic. WLED uses old bootloaders which are only working correctly with mode DOUT / DIO.

[vortigont]

NAND's has different organization, it can't access data per byte, only by page/block. So it does not allow executing code from ROM. All esp's are using NORs for code storage.

@Jason2866 if I'm not mistaken flash mode DIO / DOUT only affects how chip is flashed during fw upload, it does not alter how it operates when code is executed. Anyway, I've tried it already both options - it does not help :(

[Jason2866]

No flash mode setup is which Flash mode is used when running the firmware!
First level boot loader can not run mode QIO!! It always start in mode DOUT or DIO.
The flash mode is the command to tell the 2nd stage bootloader to try to activate mode QIO with the vendor specific code in IDF.

[Jason2866]

Honestly I doubt your setup for mode DIO was correct

[vortigont]

Honestly I doubt your setup for mode DIO was correct

anything except "flash_mode": "dio" is requred? I will retry again

Wonder how it works with PSRAM flag then, dunno...

[TD-er]

Wonder how it works with PSRAM flag then, dunno...

Could be that the PSRAM flag also changes flags for the compiler/linker to place some specific functions in IRAM which may result in less read access to the flash chip, which may just be enough to let it pass some tests during boot.

[Jason2866]

anything except "flash_mode": "dio" is requred? I will retry again

Maybe low quality Flash chips needs 40Mhz flash frequency too.

[vortigont]

OK, so with another bunch of tests. Indeed you was right @Jason2866, it works with "flash_mode": "dio" with bundled flash chip and proper cleanup. I suspect that PSRAM flag either cancels switching qio mode for flash or, probably uses another bootloader for quad psram operation. Did not get that far to understand the difference in boot code.
I've changed the manifests - added WF4 board and set variant to target definitions from Arduino's core.

Thanks a lot for the help on this!

[Jason2866]

@vortigont Do you know a source for the wf4 board (esp32-s3)? Prefered Aliexpress (delivery country Germany)

[vortigont]

@Jason2866 I've bought mine from this store sometime ago.
They have Huidu and many other similar boards for HUB75 panels.

[Jason2866]

Thx. No items listed. Probably not selling to Germany