ANNOUNCE: Squeezelite-ESP32 (dedicated thread)

[wizmo]

All you need is an ESP32-CAM, a bluetooth speaker...

and an LED strip

This is a subtle ploy to get my PR merged!

[philippe_44]

and an LED strip

This is a subtle ploy to get my PR merged!

It's really nice. The problem I'm having right now is the struggle with flash space on the esp32. I don't want to multiply builds and we have the difficulty of upward compatibility if we move to 8MB flash (knowing that most devices are 8MB already but they are partitioned for 4MB, and doing OTA repartitioning is a good recipe for many people shipping SqueezeAMP back to me)

[philippe_44]

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!

Did you wipe it out with espressif's tool?

[Maudiot]

Did you wipe it out with espressif's tool?

I couldn't remember if I did and immediately reflashed with Squeezelite so I just did to verify. I erased flash with ESP IDF, checked monitor on now blank device and received the same error which was expected since nothing exists at 0x1000 to boot from and then reflashed with Squeezelite web installer. Still getting the same error. I'm thinking these boards are either mislabeled or faulty but if there's any other testing you want me to perform I'm happy to, Thanks again for all the work you have put in this.

[nenu]

I couldn't remember if I did and immediately reflashed with Squeezelite so I just did to verify. I erased flash with ESP IDF, checked monitor on now blank device and received the same error which was expected since nothing exists at 0x1000 to boot from and then reflashed with Squeezelite web installer. Still getting the same error. I'm thinking these boards are either mislabeled or faulty but if there's any other testing you want me to perform I'm happy to, Thanks again for all the work you have put in this.

This all sounds very familiar and similar to a problem I was having and based on the log files was diagnosed by sle118 here as an issue with flash memory. That is a WROVER Devkit C module.

Then very recently, looking for a WLED controller, I decided to give this module another shot. And on WLED it worked well for over a week so far.
I also read about possible issues with the pins, but haven't tried removing them yet.

So it looks like WLED is far less peculiar about these issues? Maybe it just doesn't use the same amount of memory in the same way.

[fmarquez]

Turnoff Led

Good evening
First of all, thank you for this great work that helps us so much.
I would like to see if anyone knows which pin the green led is connected to. I have a board like the one shown in #1721 but I can't turn off the led with the set_GPIO parameter or with the led_brightness parameter.
I think I'm not hitting the correct pin or I'm doing something wrong.
I have tried with pin 5, 22 and some other but without success
I appreciate any comment that clarifies my ideas

[philippe_44]

This all sounds very familiar and similar to a problem I was having and based on the log files was diagnosed by sle118 here as an issue with flash memory. That is a WROVER Devkit C module.

Then very recently, looking for a WLED controller, I decided to give this module another shot. And on WLED it worked well for over a week so far.
I also read about possible issues with the pins, but haven't tried removing them yet.

So it looks like WLED is far less peculiar about these issues? Maybe it just doesn't use the same amount of memory in the same way.

The difference mug he be that we use the flash in QIO mode at maximum bus speed (80MHz) so it’s probably less forgiving to bad design. Now, is the OP sure that the issue happened with nothing connected on the GPIOs and q fully blanked flash (NVS needs to be erased)

[edw5]

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

I have two boards, a muse luxe speaker and a dev board with a camera interface, both using the original WROVER (no suffix). Espressif also produces a WROVER-B and WROVER-E; since I don't have access to either my comments on those are based on data sheets and the ESP-IDF bug tracker.

The pictures are of my dev board, which identifies as D0WDQ6 revision 1.

[email protected]:~$ esptool.py flash_id
esptool.py v3.3-dev
Found 1 serial ports
Serial port /dev/ttyUSB0
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: c8:c9:a3:d8:1f:48
Uploading stub...
Running stub...
Stub running...
Manufacturer: c8
Device: 6016
Detected flash size: 4MB
Hard resetting via RTS pin...

According to their data sheets the WROVER-B should identify as D0WD and the WROVER-E as D0WD-V3. The WROVER has a bootloader date of Jun 8 2016 whereas the WROVER-E appears to have a bootloader date of Jul 29 2019; I don't know what bootloader date the WROVER-B has.

The WROVER and WROVER-B both make the pins that interface to the on-chip flash available externally on CLK, CMD, and SD0-SD3, and these dev boards connect those all the way to pins near the USB connector on the board. Espressif specifically recommends against connecting the flash pins externally, and on the WROVER-E all six pins are NC. Therefore, a board with a genuine WROVER-E is not susceptible to the issue discussed here, although there is a WROVER-E flash corruption issue discussed elsewhere in this thread.

My dev board worked fine with all the Espressif samples I tried and worked with squeezelite-esp32 provided nothing was touching the flash pins. As soon as I plugged the board into a breadboard squeezelite-esp32 would go into a bootloop due to flash read errors, although the Espressif samples, which run the clocks at slower settings, still worked.

As shown in the pictures, I broke the flash pins to prevent them making contact with the breadboard, and squeezelite-esp32 now runs again on my board. It wouldn't surprise me if some boards have more sensitive flash interfaces than others, which would explain the reports of boards that won't boot squeezelite-esp32 even without external connections to those pins.

Once again, a genuine WROVER-E cannot be affected by this issue.

[Maudiot]

The difference mug he be that we use the flash in QIO mode at maximum bus speed (80MHz) so it’s probably less forgiving to bad design. Now, is the OP sure that the issue happened with nothing connected on the GPIOs and q fully blanked flash (NVS needs to be erased)

I wanted to be sure before replying so I just "esptool.py --chip esp32 erase_flash" twice to be sure, previously I did not use the chip argument, and it appeared to complete the operation. Next I reflashed with the squeezelite web installer latest 16bit version with erase flash checked, nothing connected to board and nothing touching an pins and still the same issue. Also in case it got overlooked in an earlier post on 2 separate boards squeezelite booted immediately after flashing and I was able to access the AP enter wifi credentials and access the config pages but after a hard reboot it would no longer load; on a third I unplugged before testing and am unsure if it ever booted properly.

[dpeddi]

Thanks, MumPf, this is my demo working button configuration:

I got during my tests some issues, so thought to make this video to show you the cases. It's pretty frustrating to understand if it's a server fault or esp32 flat, please feel free to examine it.
[...]

Hello,

do you think it would be possible for you to share your 3d printed case project?

thank you

[Maudiot]

The difference mug he be that we use the flash in QIO mode at maximum bus speed (80MHz) so it’s probably less forgiving to bad design. Now, is the OP sure that the issue happened with nothing connected on the GPIOs and q fully blanked flash (NVS needs to be erased)

I ordered a different brand of board and it worked without any issues so I am giving up on the other ones. I did have a couple of minor issues that I am still trying to work out. My DAC is I2S and like in the reported issue on github I had to configure it through NVS but it's working great now. The other one I am still trying to figure out. I have added a rotary encoder for volume and play/pause control, this configuration was accepted through the web interface and the volume control works perfectly. The button is only half working though, it will pause but not resume. If I understand the docs correctly it should be toggle by default. I have been trying to connect through telnet to see what logs are available but keep getting a "connection refused" error in putty. I have also looked at trying to define the encoder push button separately but I can't seem to understand exactly how and where the json encoding works/goes. Sorry for any stupid questions this just seems to be beyond me.

[philippe_44]

I ordered a different brand of board and it worked without any issues so I am giving up on the other ones. I did have a couple of minor issues that I am still trying to work out. My DAC is I2S and like in the reported issue on github I had to configure it through NVS but it's working great now. The other one I am still trying to figure out. I have added a rotary encoder for volume and play/pause control, this configuration was accepted through the web interface and the volume control works perfectly. The button is only half working though, it will pause but not resume. If I understand the docs correctly it should be toggle by default. I have been trying to connect through telnet to see what logs are available but keep getting a "connection refused" error in putty. I have also looked at trying to define the encoder push button separately but I can't seem to understand exactly how and where the json encoding works/goes. Sorry for any stupid questions this just seems to be beyond me.

If you want just volume up/down and play toggle, you have to set the "volume" option of the rotary_config (https://github.com/sle118/squeezelit...rotary-encoder). Re telnet, you have to enable it first in the UI

[Maudiot]

If you want just volume up/down and play toggle, you have to set the "volume" option of the rotary_config (https://github.com/sle118/squeezelit...rotary-encoder). Re telnet, you have to enable it first in the UI

Thanks again for the quick reply. I should have been more detailed.

I have set the volume option check box and verified that volume was included in the rotary_config NVS parameter.

I have also enable telnet from the drop down and verified that Y is present in the telnet_enable parameter.

I have switched the GPIO from 23 to 19 to verify it's not a GPIO problem.

[piPlayer]

I got the SSD1305 display to work.
All I had to do was change the COM pin configuration in the ssd1306.c file line 122 from 0xda to 0x12.

// COM pins HW configuration (alternatively:EN if 64, DIS if 32, remap:DIS) - some displays might need something else
	Device->WriteCommand( Device, [COLOR="#FF0000"]0xDA[/COLOR] );

// COM pins HW configuration (alternatively:EN if 64, DIS if 32, remap:DIS) - some displays might need something different
	Device->WriteCommand( Device, [COLOR="#008000"]0x12[/COLOR] );

Is it possible to add a small horizontal display offset by changing this code ...

 // Display offset
    Device->WriteCommand( Device, 0xD3 );
    Device->WriteCommand( Device, [COLOR="#FF0000"]0[/COLOR] );

to this one?

 // Display offset
    Device->WriteCommand( Device, 0xD3 );
    Device->WriteCommand( Device, [COLOR="#008000"]0x01[/COLOR] );

[Syco54645]

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

No problem. Finally have a 3d printable case that will work so back to make more. Thank you for all of the help, it may just be a placebo but to me it sounds better than the pi with the stock headphone port. If nothing else it is certainly louder!