ANNOUNCE: Squeezelite-ESP32 (dedicated thread)

[Syco54645]

Just to be clear, the 4 solder jumpers shown already do what you suggest. The exception is the XSMT pin, which is high, but connected to 3.3V through a voltage divider.

I was unsure what the pads did on the module. I searched but came up empty. It sounds like I can remove a bit of wiring by using them. If so that will cut down my build time a bit, I have at least 2 more to make.

[mboxler]

I was unsure what the pads did on the module. I searched but came up empty. It sounds like I can remove a bit of wiring by using them. If so that will cut down my build time a bit, I have at least 2 more to make.

As I said earlier, you only need to connect 5 wires and it will work. Everything else is already connected properly using the bottom jumpers as delivered. If you have good eyes and a steady hand, you can also eliminate the SCK to ground wire by applying a solder bridge to the jumper next to the SCK hole (on the top of the board).

[Syco54645]

As I said earlier, you only need to connect 5 wires and it will work. Everything else is already connected properly using the bottom jumpers as delivered. If you have good eyes and a steady hand, you can also eliminate the SCK to ground wire by applying a solder bridge to the jumper next to the SCK hole (on the top of the board).

None of my boards have the jumpers already connected. I will just replicate what is in the picture on here. That greatly simplifies things. Thank you for re-explaining it.

[mboxler]

None of my boards have the jumpers already connected. I will just replicate what is in the picture on here. That greatly simplifies things. Thank you for re-explaining it.

Sorry about that! I just assumed all the jumpers were already pre-soldered, except SCK. That's how my board was delivered.

[Maudiot]

Not booting after successful flash

I am having a problem I can't seem to figure out. I have flashed 3 of https://www.amazon.com/ACEIRMC-ESP32.../dp/B0B3JD1K1T and they have all ended up in an "Flash read err 1000" state that I can't seem to figure out how to fix. I have tried reprogramming them multiple times with the web tool, loading a factory bootloader with espressifs web programmer tool, compiled and flashed a sample program with both their cli program and the Arduino IDE but nothing seems to work. I have included logs for the last one I flashed beginning with a factory fresh boot, then the after flashing log and finally the after hard reset log. What appears to happen is that they don't survive a hard reboot. After flashing the seem to work as expected, I was able to configure wifi through the AP and the web interface was accessible on my local network afterwards on the last 2. After unplugging them from my pc and powering them from an apple brick that has been running a Pi Zero W for over a year with no issues they will no longer boot. The first one had the same error and it was never plugged into the brick but I was also unable to verify it ever booted properly.

ESP32 3rd As Received.txt
ESP32 3rd After Flash and Wifi Config.txt
ESP32 3rd After Hard Reset(remove power).txt

[sle118]

I am having a problem I can't seem to figure out. I have flashed 3 of https://www.amazon.com/ACEIRMC-ESP32.../dp/B0B3JD1K1T and they have all ended up in an "Flash read err 1000" state that I can't seem to figure out how to fix. I have tried reprogramming them multiple times with the web tool, loading a factory bootloader with espressifs web programmer tool, compiled and flashed a sample program with both their cli program and the Arduino IDE but nothing seems to work. I have included logs for the last one I flashed beginning with a factory fresh boot, then the after flashing log and finally the after hard reset log. What appears to happen is that they don't survive a hard reboot. After flashing the seem to work as expected, I was able to configure wifi through the AP and the web interface was accessible on my local network afterwards on the last 2. After unplugging them from my pc and powering them from an apple brick that has been running a Pi Zero W for over a year with no issues they will no longer boot. The first one had the same error and it was never plugged into the brick but I was also unable to verify it ever booted properly.

[ATTACH]39203[/ATTACH]
[ATTACH]39204[/ATTACH]
[ATTACH]39205[/ATTACH]

Other users have reported a similar issue with similar devices (e.g. Wrover boards with cameras), so I ordered a few of them to test and the bottom line was that I waas never able to reproduce the problem myself. Since you have installed Espressif's toolset, you might want to dump the eFuse values to check if these chips have the encryption bit enabled. Reading the documentation (see link below) would seem to indicate that flashing non-encrypted bootloader (like squeezelite-esp32) with that bit enabled would result in exactly the message you're seeing.

https://docs.espressif.com/projects/esp-idf/en/v4.3/esp32/security/flash-encryption.html#possible-failures

Please check and report back. The solution is simple: using the eFuse tool, disable the encryption flag

[Maudiot]

Other users have reported a similar issue with similar devices (e.g. Wrover boards with cameras), so I ordered a few of them to test and the bottom line was that I waas never able to reproduce the problem myself. Since you have installed Espressif's toolset, you might want to dump the eFuse values to check if these chips have the encryption bit enabled. Reading the documentation (see link below) would seem to indicate that flashing non-encrypted bootloader (like squeezelite-esp32) with that bit enabled would result in exactly the message you're seeing.

https://docs.espressif.com/projects/esp-idf/en/v4.3/esp32/security/flash-encryption.html#possible-failures

Please check and report back. The solution is simple: using the eFuse tool, disable the encryption flag

Thanks for the quick response, this is an awesome project! Below is the monitor log from ESP-IDF after flashing the flash_encryption program per the link you provided. It appears that it is not encrypted, see bold text, unless I am misunderstanding something. I assume this means the bootloader is corrupt per the link but isn't it reflashed along with the partition table via your web programmer? I tried reflashing it again but still get the same result.

rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
flash read err, 1000
ets_main.c 371 
ets Jun  8 2016 00:22:57

Could the boards be a bad knockoff? Is there any way to test?

PS C:\Espressif\frameworks\esp-idf-v4.4.3\examples\security\flash_encryption> idf.py monitor
Executing action: monitor
Serial port COM3
Connecting....
Detecting chip type... Unsupported detection protocol, switching and trying again...
Connecting....
Detecting chip type... ESP32
Running idf_monitor in directory c:\espressif\frameworks\esp-idf-v4.4.3\examples\security\flash_encryption
Executing "C:\Espressif\python_env\idf4.4_py3.8_env\Scripts\python.exe C:\Espressif\frameworks\esp-idf-v4.4.3\tools/idf_monitor.py -p COM3 -b 115200 --toolchain-prefix xtensa-esp32-elf- --target esp32 --revision 0 c:\espressif\frameworks\esp-idf-v4.4.3\examples\security\flash_encryption\build\flash_encryption.elf -m 'C:\Espressif\python_env\idf4.4_py3.8_env\Scripts\python.exe' 'C:\Espressif\frameworks\esp-idf-v4.4.3\tools\idf.py'"...
--- WARNING: GDB cannot open serial ports accessed as COMx
--- Using \\.\COM3 instead...
--- idf_monitor on \\.\COM3 115200 ---
--- Quit: Ctrl+] | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H ---
ets Jun  8 2016 00:22:57

rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0030,len:6660
load:0x40078000,len:14852
load:0x40080400,len:3792
0x40080400: _init at ??:?

entry 0x40080694
I (27) boot: ESP-IDF v4.4.3 2nd stage bootloader
I (27) boot: compile time 11:54:02
I (27) boot: chip revision: 1
I (29) boot_comm: chip revision: 1, min. bootloader chip revision: 0
I (37) boot.esp32: SPI Speed      : 40MHz
I (41) boot.esp32: SPI Mode       : DIO
I (46) boot.esp32: SPI Flash Size : 2MB
I (50) boot: Enabling RNG early entropy source...
I (56) boot: Partition Table:
I (59) boot: ## Label            Usage          Type ST Offset   Length
I (67) boot:  0 nvs              WiFi data        01 02 0000a000 00006000
I (74) boot:  1 storage          Unknown data     01 ff 00010000 00001000
I (81) boot:  2 factory          factory app      00 00 00020000 00100000
I (89) boot:  3 nvs_key          NVS keys         01 04 00120000 00001000
I (96) boot: End of partition table
I (101) boot_comm: chip revision: 1, min. application chip revision: 0
I (108) esp_image: segment 0: paddr=00020020 vaddr=3f400020 size=08240h ( 33344) map
I (128) esp_image: segment 1: paddr=00028268 vaddr=3ffb0000 size=02334h (  9012) load
I (132) esp_image: segment 2: paddr=0002a5a4 vaddr=40080000 size=05a74h ( 23156) load
I (145) esp_image: segment 3: paddr=00030020 vaddr=400d0020 size=17470h ( 95344) map
I (180) esp_image: segment 4: paddr=00047498 vaddr=40085a74 size=061fch ( 25084) load
I (190) esp_image: segment 5: paddr=0004d69c vaddr=50000000 size=00010h (    16) load
I (197) boot: Loaded app from partition at offset 0x20000
I (197) boot: Disabling RNG early entropy source...
I (211) cpu_start: Pro cpu up.
I (211) cpu_start: Starting app cpu, entry point is 0x4008103c
0x4008103c: call_start_cpu1 at C:/Espressif/frameworks/esp-idf-v4.4.3/components/esp_system/port/cpu_start.c:148

I (0) cpu_start: App cpu up.
I (225) cpu_start: Pro cpu start user code
I (225) cpu_start: cpu freq: 160000000
I (225) cpu_start: Application information:
I (230) cpu_start: Project name:     flash_encryption
I (235) cpu_start: App version:      v4.4.3
I (240) cpu_start: Compile time:     Nov 24 2022 11:47:58
I (246) cpu_start: ELF file SHA256:  aa53da373b57b73e...
I (252) cpu_start: ESP-IDF:          v4.4.3
I (257) heap_init: Initializing. RAM available for dynamic allocation:
I (264) heap_init: At 3FFAE6E0 len 00001920 (6 KiB): DRAM
I (270) heap_init: At 3FFB2C48 len 0002D3B8 (180 KiB): DRAM
I (277) heap_init: At 3FFE0440 len 00003AE0 (14 KiB): D/IRAM
I (283) heap_init: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM
I (289) heap_init: At 4008BC70 len 00014390 (80 KiB): IRAM
I (297) spi_flash: detected chip: generic
I (300) spi_flash: flash io: dio
W (304) spi_flash: Detected size(4096k) larger than the size in the binary image header(2048k). Using the size in the binary image header.
I (318) cpu_start: Starting scheduler on PRO CPU.
I (0) cpu_start: Starting scheduler on APP CPU.

Example to check Flash Encryption status
This is esp32 chip with 2 CPU core(s), WiFi/BT/BLE, silicon revision 1, 2MB external flash
[B]FLASH_CRYPT_CNT eFuse value is 0
Flash encryption feature is disabled[/B]
Erasing partition "storage" (0x1000 bytes)
Writing data with esp_partition_write:
I (493) example: 0x3ffb5900   00 01 02 03 04 05 06 07  08 09 0a 0b 0c 0d 0e 0f  |................|
I (503) example: 0x3ffb5910   10 11 12 13 14 15 16 17  18 19 1a 1b 1c 1d 1e 1f  |................|
Reading with esp_partition_read:
I (513) example: 0x3ffb58e0   00 01 02 03 04 05 06 07  08 09 0a 0b 0c 0d 0e 0f  |................|
I (523) example: 0x3ffb58f0   10 11 12 13 14 15 16 17  18 19 1a 1b 1c 1d 1e 1f  |................|
Reading with spi_flash_read:
I (533) example: 0x3ffb58e0   00 01 02 03 04 05 06 07  08 09 0a 0b 0c 0d 0e 0f  |................|
I (543) example: 0x3ffb58f0   10 11 12 13 14 15 16 17  18 19 1a 1b 1c 1d 1e 1f  |................|

[sle118]

Thanks for the quick response, this is an awesome project! Below is the monitor log from ESP-IDF after flashing the flash_encryption program per the link you provided. It appears that it is not encrypted, see bold text, unless I am misunderstanding something. I assume this means the bootloader is corrupt per the link but isn't it reflashed along with the partition table via your web programmer? I tried reflashing it again but still get the same result.

rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
flash read err, 1000
ets_main.c 371 
ets Jun  8 2016 00:22:57

Could the boards be a bad knockoff? Is there any way to test?

you could try running this command

python components/esptool_py/esptool/esptool.py flash_id

and see if the chip can be identified correctly.

This project pushes SPI bus speed to QIO 80M so I'm guessing that boards with quality issue might not be able to keep up, but I'm no specialist. You could also compare the output of efuse for all your boards and see if there are differences between them as well. Might not be a knock off, but this problem looks like it's caused by hardware.

[edw5]

As I said a while back, all these small dev boards with a camera attachment seem to use the original WROVER and bring the internal flash connections out to pins on the board. That's not recommended by Espressif, and can result in enough noise on the flash interface to stop it working properly, especially when the clocks are set to their maximum values. The WROVER-E was changed such that the flash connections are no longer available outside the chip, presumably to prevent exactly this sort of issue.

With the board I have, I cut the relevant pins off with pliers and the problem went away. Those pins can't be used for anything, so there's no downside to removing them (provided you make sure you remove the right ones).

[sle118]

As I said a while back, all these small dev boards with a camera attachment seem to use the original WROVER and bring the internal flash connections out to pins on the board. That's not recommended by Espressif, and can result in enough noise on the flash interface to stop it working properly, especially when the clocks are set to their maximum values. The WROVER-E was changed such that the flash connections are no longer available outside the chip, presumably to prevent exactly this sort of issue.

With the board I have, I cut the relevant pins off with pliers and the problem went away. Those pins can't be used for anything, so there's no downside to removing them (provided you make sure you remove the right ones).

That makes total sense. Would you mind taking a picture of one of your board? I would link your explanation to the issue in Github

[Maudiot]

Unfortunately I still don't have this working, I'm hoping the following information either helps fix the problem or determine if there are some incompatible boards floating around and helps ID them.

I ran the flash ID command and received the following.

PS C:\Espressif\frameworks\esp-idf-v4.4.3\examples\wifi> esptool.py flash_id
esptool.py v3.3.2
Found 1 serial ports
Serial port COM3
Connecting....
Detecting chip type... Unsupported detection protocol, switching and trying again...
Connecting....
Detecting chip type... ESP32
Chip is ESP32-D0WDQ6 (revision 1)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: ec:62:60:9b:01:00
Uploading stub...
Running stub...
Stub running...
Manufacturer: 5e
Device: 4016
Detected flash size: 4MB
Hard resetting via RTS pin...

I also unsoldered the 6 pins that appear to go to the flash memory, here are a couple pictures of the board



After this I reflashed with 2.1231 and received the same error. I then flashed with the WLED web installer which appears to be similar and it was successful.

[sle118]

After this I reflashed with 2.1231 and received the same error. I then flashed with the WLED web installer which appears to be similar and it was successful.

When you say it was successful. You mean the board works, or flash was successful? One of the web installer out there has outdated binaries. I keep this one up to date:

https://sle118.github.io/squeezelite-esp32-installer/

[Maudiot]

When you say it was successful. You mean the board works, or flash was successful? One of the web installer out there has outdated binaries. I keep this one up to date:
https://sle118.github.io/squeezelite-esp32-installer/

Sorry that wasn't very clear. That is the web installer I have been using for Sqeezelite. To make sure nothing on the board was damaged after removing pins I decided to flash it with a different piece of software. Since https://install.wled.me/ appears very similar to your installer I decided to try it and it was successful at installing WLED, not squeezelite.

[edw5]

Sorry I haven't posted pictures of my board yet, it's not easily accessible and I haven't had the time to get to it. The board that the other poster has posted pictures of looks questionable to me. The correct pins have been removed (and much more tidily than I did mine), but the chip seems to be marked as a WROVER-E but identified as D0WDQ6. That combination doesn't exist: WROVER-E is V3 of the ESP32, but D0WDQ6 is the earliest production run of the ESP32.

I wouldn't trust that board at all.

[Maudiot]

Sorry I haven't posted pictures of my board yet, it's not easily accessible and I haven't had the time to get to it. The board that the other poster has posted pictures of looks questionable to me. The correct pins have been removed (and much more tidily than I did mine), but the chip seems to be marked as a WROVER-E but identified as D0WDQ6. That combination doesn't exist: WROVER-E is V3 of the ESP32, but D0WDQ6 is the earliest production run of the ESP32.

I wouldn't trust that board at all.

That makes a lot of sense. I'm inclined to agree, there is something not right even though it shows the proper amount of memory etc, and that would explain it. When the Amazon photo shows a solder bridge on pins that might be a good indicator not to buy lol. I've ordered a couple of different boards to try now to decide if I want to try returning a slightly modified incorrectly labeled one.


Thanks everyone for the help!