ANNOUNCE: Squeezelite-ESP32 version 2.x

[sle118]

I have two remarks about Squeezelite-ESP32 firmware version display.

1) Firmware version display in LMS
After installing v2.x firmware on my ESP Muse Luxe, LMS still reports a v1.x firmware version.
For example, after flashing firmware version 2.1227-16, LMS reports "Firmware: v1.0-1227-16" on its Information tab.
This is not a big deal, but for consistency it would be nice if this can be fixed.

2) Firmware version display on Squeezelite-ESP32 web GUI status bar
I have noticed that with the most recent firmware version (v2.1227-16) the web GUI does not show the platform nor the firmware version on its status bar.

For example, with firmware version v2.1223 both the platform (in my case I2S-4MFlash) and the firmware version (1223) are displayed on the status bar:
[ATTACH]39218[/ATTACH]
This is how I like it.

But with firmware version v2.1227, platform and firmware version are not displayed:
[ATTACH]39219[/ATTACH]
This is not convenient, since in this case the user cannot see which firmware is running on his/her ESP32 device, and also not if the latest available firmware shown on the Update tab is newer than the firmware that is currently running on the device.
It would be nice if this issue can be fixed in future firmware versions.

I've been working on getting a new build system online and some firmware versions were produced with it. I'm glad you're reporting this because I had not noticed this before. I will launch a release build with the old workflow so the newest version doesn't report "local" and push it to the web installer soon.

[CJS]

I will launch a release build with the old workflow so the newest version doesn't report "local" and push it to the web installer soon.

OK, thanks in advance.

Update: I just flashed firmware I2S-4MFlash v2.1230, and now the firmware version display in the Squeezelite-ESP32 web GUI is OK:



LMS still reports v1 firmware (Firmware: v1.0-1230-16), but I can live with that. Thanks!

[slimhase]

So, I captured a logfile:
(Before that I erased via web installer the device and loaded the latest 16 bit FW - I can confirm that it loaded the 16 bit Version. I connected it to my WLAN. I did not edit any config - also I ran wo my display connected.)

I started the log:
1st playing some audio stream to confirm it works.
Then at Line 84 I switched the player off via LMS
Then at Line 87 I switch the hardware Power-Off switch on SqueezeAmp - and here the reboot loop starts
Somewhere at the end of the log I switch the hardware Power-On again and the system runs normally
-> Does this give you any clues?
[ATTACH]39209[/ATTACH]

[edit] ... and for reference the same sequence with running fw1180:
[ATTACH]39210[/ATTACH]
When I switch the hardware Powerbutton, the system states "Guru M" and powers down as expected (instead of reboot loop) - Line 62
In Line 64 the system resumes after switching hardware switch to on again.

@sle118 and @philippe44 - anything in the logs which could explain the situation?

I have another (related?) observation (when on FW 1180, where switch "works"):

When I have my serial logger connected (providing external 3.3V to ESP), I would have assumed that toggeling the power switch has no affect (as it should only switch the internal 3.3V) - but it has an affect:

Switch to power on: ESP connects to WLAN (i.e. accessible through Web-Interface ) and Serial communication works. fw1180pwrswitch_on.log

Switch to power off: ESP does NOT connect WLAN - but Serial communication works!! (and ESP responds to reset button) fw1180pwrswitch_off.log

How can that be? Does this give you any clue?
(The logs look identical to me, but maybe I am overlooking something)

I really hope you can find the issue....(since I want to help to continue w/ troubleshooting, I have the Speaker w/ the SqueezeAmp inside dismanteled - so no music for me these days....)

[sle118]

@sle118 and @philippe44 - anything in the logs which could explain the situation?

I have another (related?) observation (when on FW 1180, where switch "works"):

When I have my serial logger connected (providing external 3.3V to ESP), I would have assumed that toggeling the power switch has no affect (as it should only switch the internal 3.3V) - but it has an affect:

Switch to power on: ESP connects to WLAN (i.e. accessible through Web-Interface ) and Serial communication works. [ATTACH]39226[/ATTACH]

Switch to power off: ESP does NOT connect WLAN - but Serial communication works!! (and ESP responds to reset button) [ATTACH]39225[/ATTACH]

How can that be? Does this give you any clue?
(The logs look identical to me, but maybe I am overlooking something)

I really hope you can find the issue....(since I want to help to continue w/ troubleshooting, I have the Speaker w/ the SqueezeAmp inside dismanteled - so no music for me these days....)

Here is the schematics from the latest version of the board, as published on Philippe's repo. There's really nothing much there that could interact with the firmware as such.


I just noticed that there are two types of reset happening

rst:0xf (RTCWDT_BROWN_OUT_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)

rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)

This seems to indicate a power issue?

[slimhase]

Here is the schematics from the latest version of the board, as published on Philippe's repo. There's really nothing much there that could interact with the firmware as such.

I just noticed that there are two types of reset happening

rst:0xf (RTCWDT_BROWN_OUT_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)

rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)

This seems to indicate a power issue?

According to my logs, the BROWN_OUT only happens in the case of the switch beeing off *** and only with fw > 1180 ***

(And my powersupply is rated 14V 4A, so this should not be marginal)

I will do some voltage measurments on the weekend - may be the brown-out definition is different in the 2.x compiler setup?

Are there also potential older / initial versions of the these circuit diagrams available?

Thanks for your help!

[ralphy]

LMS still reports v1 firmware (Firmware: v1.0-1230-16), but I can live with that. Thanks!

The v1.0 is likely from squeezelite.h.

Changing MAJOR_VERSION to 2 should fix it.

[sle118]

The v1.0 is likely from squeezelite.h.

Changing MAJOR_VERSION to 2 should fix it.

I suggested an approach to Philippe to allow synchronizing with our version scheme during the build. I'll see what he thinks.

thanks!

[slimhase]

The plot thickens....

This post is about my SqueezeAmp going into reboot loop since FW 2.x update when Power Switch (J7) is switched to OFF (not happening with FW 1.x)

According to my logs, the BROWN_OUT only happens in the case of the switch beeing off *** and only with fw > 1180 ***

(And my powersupply is rated 14V 4A, so this should not be marginal)

I will do some voltage measurments on the weekend - may be the brown-out definition is different in the 2.x compiler setup?

Thanks for your help!

So my measurements revealed something really strange and probably the culprit of the problem:

When the switch is set to ON, I measure 3,3V on the 3.3V pin (as expected)

BUT: When the switch is set to OFF, I can still measure 0,95V on that Pin (*)!
And looking at my logs, the ESP still seems to respond (i.e. works) when supplied with 0,95V!!

This is how I think the different behavior depending on the Firmware-Version comes into play:

When running FW 1.x, the system goes into proper power off (last Log message "Guru M") when supply switches from 3,3V to 0,95V
When running FW 2.x, the system goes into a brown out reboot loop when supply switches from 3,3V to 0,95V

-> My question to you guys (philippe44 and / or sle118):


Can you tweak some setting (i.e. complier setting, other...?), so that 2.x behaves similar to 1.x in terms of brown out detection?
(-> going into power down instead of brown out when switched from 3,3V to 0,95V)


(*) I measure 0,95V when the serial logger is connected (but only TX, RX, RST, DWL and GND - NOT providing 3.3V through the logger) and 0,25V when nothing is connected to the stated pins)


**** update ****
Well, it is still more complicated (and more puzzeling) than I stated above.
Because additionally, I did now the same measurements as above, but now with the latest 2.x FW:
Here, the voltage I measured is 3,3V - regardless, if I have the switch in on or off position!
(In the off position, there has to be a brief voltage-drop at some point, because otherwise I would not get the brown-out message in the log)

Another interesting fact (FW 2.x):
When I unplug all power (external and battery), then put the switch to Off and then plug the battery in again: The system stays off!
When I then leave the battery connected and switch to On - the system powers on.
Switching now to off brings me back into the reboot loop.

-> I am clueless as to what is going on here.... :-(

[CJS]

This post is about my SqueezeAmp going into reboot loop since FW 2.x update when Power Switch (J7) is switched to OFF (not happening with FW 1.x)
**** update ****
Well, it is still more complicated (and more puzzeling) than I stated above.
Because additionally, I did now the same measurements as above, but now with the latest 2.x FW:
Here, the voltage I measured is 3,3V - regardless, if I have the switch in on or off position!
(In the off position, there has to be a brief voltage-drop at some point, because otherwise I would not get the brown-out message in the log)

Are you using long wires to the ON/OFF switch connected to connector J7? I am using my SqueezeAMP without ON/OFF switch, but I once connected a switch to J7 and noticed that pin 5 (EN pin) of the buck converter is very sensitive for interference. The EN pin has an internal high-ohmic pull-up resistor to VIN, which makes it sensitive for interference. With switch opened and touching the wire connected to pin 5 with a finger or a screwdriver, I noticed that the buck converter was repeatedly switched ON and OFF.

[slimhase]

Are you using long wires to the ON/OFF switch connected to connector J7? I am using my SqueezeAMP without ON/OFF switch, but I once connected a switch to J7 and noticed that pin 5 (EN pin) of the buck converter is very sensitive for interference. The EN pin has an internal high-ohmic pull-up resistor to VIN, which makes it sensitive for interference. With switch opened and touching the wire connected to pin 5 with a finger or a screwdriver, I noticed that the buck converter was repeatedly switched ON and OFF.

Maybe that is the rootcause.
However, I can not confirm, because with wires dangling around I must have fried something now during testing :-(((
The LED which normally blinks green when connected now erratically flashes red.
Very frustrating. No more SqueezeAmp for me - due to my stupidity....

(When I get a serial reading from the module it states this in a loop:
"rst:0x10 (RTCWDT_RTC_RESET),boot:0x1f (SPI_FAST_FLASH_BOOT)
flash read err, 1000
ets_main.c 371
ets Jun 8 2016 00:22:57"

But I must have fried something more severe, as when I get the erratic red flashing, Vcc drops with it (not only 3.3V, but the higher Vcc)

Stupid me - really angry with myself for not paying more attention to "clean desk policy" on my workbench......

[slimhase]

Its alive!!

Maybe that is the rootcause.
However, I can not confirm, because with wires dangling around I must have fried something now during testing :-(((
The LED which normally blinks green when connected now erratically flashes red.
Very frustrating. No more SqueezeAmp for me - due to my stupidity....

(When I get a serial reading from the module it states this in a loop:
"rst:0x10 (RTCWDT_RTC_RESET),boot:0x1f (SPI_FAST_FLASH_BOOT)
flash read err, 1000
ets_main.c 371...."

But I must have fried something more severe, as when I get the erratic red flashing, Vcc drops with it (not only 3.3V, but the higher Vcc)

Stupid me - really angry with myself for not paying more attention to "clean desk policy" on my workbench......

Thankfully, I was able to repair my SqueezeAmp:
The ESPWrover on the SqueezeAmp was definetely dead: Even in programming mode, it was stuck in the quoted flash read error boot loop.
So, I replaced the ESP on the SqueezeAmp (not so easy...).
And - the system booted up again!

I then replaced the power switch cable with a coax cable and reduced the length from about 15 to 10cm.
And - now also with the newest Firmware the system shuts properly down via J7 switch!

So, to sum it up:
- I think @CJS suspicion is right that the Enable Pin of the 3.3V buck converter (U1) is very sensitive to interference and using longer (>10cm) non-shielded cable for the J7 Power switch are therefor a problem.
- This situation was marginal with FW 1.x (J7) in Off position generating still 0,95V) and leads to failure with FW 2.x (J7 in Off generating 3.3V)
- Also, I now think that the ESP died not because of dangling cables, but due to U1 providing very erratic power in the above state and it died (or the on board flash died)

To sum it even more up:
When using the power switch J7, USE SHORT (<10CM), SHIELDED CABLES.

[philippe_44]

The EN line of the dc/dc is directly connected to that 2 pins connector. No pull-up, as every resistor counts to make it fit (and the DC does. It require a pull-up) so I assume something happened when that long wire was floating, internal pull-up was not strong enough.

Congrats for the repair, in case others want to change the wrover, I usually heat up the middle of it with a mid-size heat gun nozzle at 400C (yes it’s hot on purpose) and very gently pulls on the antenna to remove it. It’s fast and I’ve never damaged a board. Don’t try to unsolder or clean every pad, it’s a waste of time and does not help. You can put some capton on connectors to better protect them. Soldering a new one is super easy, except for ground pads. Hold the new one firmly in place, solder 2 pins then you can release it, check it’s making full contact with the board and solder all other pins. Castellation pads made that very easy.

[sle118]

here are some recent updates from my end

• The web installer (https://sle118.github.io/squeezelite-esp32-installer/) has a new simplified look, but I am not quite satisfied with the result. I'm thinking of simplifying it further
• Better responsiveness when initiating a firmware update. I have tuned some timeouts in hope that flashing an update from the squeezelite partition will not hang forever after the device has rebooted
• There's an improv-wifi (https://www.improv-wifi.com/) branch which I am hoping to release soon. When this happens, you'll be able to take a new device, flash it and connect to your wifi right from the web installer page
• The improv-wifi branch will also change the behavior when flashing the full project; the system will now boot directly to squeezelite instead of the current behavior which is to boot to recovery by default
• And a few minor enhancements or bug fixes, for example configuring cspot won't crash the system

[piPlayer]

Is it possible to implement the SSD1305 display in one of the next updates?

[sle118]

Is it possible to implement the SSD1305 display in one of the next updates?

This is one of Philippe's brainchilds, so I'll let him reply