> ESP-WROOM-32 modules can have varying flash sizes as well as varying flash chips that have differing capabilities, such as dio vs qio and 40Mhz vs 80Mhz. Your flashing of the firmware may not have gotten the right modes.
Yes, but please note that the 1.12 firmware that can be downloaded from micropython.org can be flashed to both devices and they both work. But the other firmware that I compile from source code, only works on one of them. Using the same flash mode in all 4 cases.
I'm 100% sure that the flash size is identical, because I can query the available free space (with the good firmware). The ESP chips look identical to me.
Anyway, I just checked out the v.12 tag and recompiled the firmware from scratch, without any custom modules added. Here is the log of the flashing for the factory produced devboard
Code: Select all
Use make V=1 or set BUILD_VERBOSE in your environment to increase build verbosity.
Building with ESP IDF v3
Erasing flash
esptool.py v2.8-dev
Serial port /dev/ttyUSB0
Connecting........_____....._____....._
Chip is ESP32D0WDQ6 (revision 1)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: cc:50:e3:8c:db:7c
Uploading stub...
Running stub...
Stub running...
Changing baud rate to 460800
Changed.
Erasing flash (this may take a while)...
Chip erase completed successfully in 9.4s
Hard resetting via RTS pin...
Use make V=1 or set BUILD_VERBOSE in your environment to increase build verbosity.
Building with ESP IDF v3
Writing build-GENERIC/firmware.bin to the board
esptool.py v2.8-dev
Serial port /dev/ttyUSB0
Connecting.....
Chip is ESP32D0WDQ6 (revision 1)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: cc:50:e3:8c:db:7c
Uploading stub...
Running stub...
Stub running...
Changing baud rate to 460800
Changed.
Configuring flash size...
Auto-detected Flash size: 4MB
Compressed 1241840 bytes to 783468...
Wrote 1241840 bytes (783468 compressed) at 0x00001000 in 18.2 seconds (effective 545.9 kbit/s)...
Hash of data verified.
Leaving...
Hard resetting via RTS pin...
And here is the log of flashing the custom board:
Code: Select all
╰─$ ./burn.sh
Use make V=1 or set BUILD_VERBOSE in your environment to increase build verbosity.
Building with ESP IDF v3
Erasing flash
esptool.py v2.8-dev
Serial port /dev/ttyUSB0
Connecting....
Chip is ESP32D0WDQ6 (revision 1)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: a4:cf:12:74:bf:80
Uploading stub...
Running stub...
Stub running...
Changing baud rate to 460800
Changed.
Erasing flash (this may take a while)...
Chip erase completed successfully in 8.7s
Hard resetting via RTS pin...
Use make V=1 or set BUILD_VERBOSE in your environment to increase build verbosity.
Building with ESP IDF v3
Writing build-GENERIC/firmware.bin to the board
esptool.py v2.8-dev
Serial port /dev/ttyUSB0
Connecting.......
Chip is ESP32D0WDQ6 (revision 1)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: a4:cf:12:74:bf:80
Uploading stub...
Running stub...
Stub running...
Changing baud rate to 460800
Changed.
Configuring flash size...
Auto-detected Flash size: 4MB
Compressed 1241840 bytes to 783468...
Wrote 1241840 bytes (783468 compressed) at 0x00001000 in 18.5 seconds (effective 535.8 kbit/s)...
Hash of data verified.
Leaving...
Hard resetting via RTS pin...
> The other issues are that a handful of gpio pins need to be pulled up or down at boot time ("strapping") and the board may differ in how that is handled.
I'm aware of that. I have posted the full schematic, feel free to check if there is anything wrong with it. If there is something wrong, then it still does not explain why the board works with one firmware and not the other.
> Finally, to get help, post the output of the serial port as you flash and then boot!
My build tools are under linux. If I try to connect to the custom board with putty under linux, then I do not see any message, except for one strange graphical character. Even when I press the reset button on the board, nothing comes out of the serial line. But it may be a thing with putty and the linux terminal. I know that some special charater sequences can make putty work incorrectly. I remember that I was seeing some messages on Windows. I'm going to reboot to Windows and post messages from Windows/realterm shortly.