Webinstaller Failing to Complete

[cjhoffmn]

Bug report

Problem
I have an Espressif ESP 32 WROOM-32 that was running WLED with no troubles. I wanted to install NightDriverStrip instead. However, the webinstaller is failing (and I don't have my setup right to install from source code yet).

The webinstaller:

1. Connects,
2. Starts - shows the completion circle,
3. Stops at 64%, it says it is wrapping up, then it reports a message that says that the serial port is not available, I should close anything else using the port.

I'm using the SiliconLabs CP201x USB to UART Bridge on COM4 on a Win10 Lenovo Laptop, connected directly to a USB port, using the same data cable that I am using to successfully install WLED.
Port Settings are:

• Baud: 115,200;
• Databits: 8;
• Parity: none;
• Stop Bits: 1;
• Flow Control: none

Any thoughts or ideas? Much appreciated. I'm looking forward to using this, and learning to contribute.

Steps

1. Connected via USB
2. Selected "ESP32"
3. Hit install

Example

Notes

I did have the esp32 seated in a bridge and it was connected to the lights when I did the flash at first. Subsequent attempts were done with the esp32 disconnected.
I have also successfully flashed WLED back to it.
Also, I did a hard reset of the esp32 with esptools and tried again without success.

[robertlipe]

I had a hard time bringing my board up. I ran down the default upload speeds from 1.5Mbps to 115200 because the seconds I could save weren't worth potential hours of debugging.

I also found that erasing the board's flash (I used "esptool.py --chip esp32 --port /dev/cu.usbserial-101 erase_flash" but the recipe may be different for you) was helpful in getting my board otu of the weeds.

Monitoring the system's boot logs (on Mesmerizer, it was the second interface) never gave me actionable data, but it was helpful to know if hte board was bootlooping because the flash write hadn't been successful, of if that had assed and it was a good time to retry the web flasher because only then did the options to configure local networking appear.

I had better luck initially with the web flasher at https://plummerssoftwarellc.github.io/NightDriverStrip/ just so I KNEW the binary I was squirting to the board was a working bootable image.

I sunk several hours into it. It feels like I should have found the "AHA, you forgot to configure THIS" or "move the jumper" kind of moment of clarity, but I didn't. My trip to success, such as it is, was pretty random attempts of mixing commands via esp.py, pio (which I assume wraps esp.py), and the web interface above.

Good luck.

[davepl]

Try 921600 as the baud, everything should survive that. Should not require an erase, either, though it wouldn’t hurt. With the baud set to 921600 (or even 115200), what happens when you flash it from PlatformIO? - Dave

…

On Jun 11, 2023, at 5:27 PM, Robert Lipe ***@***.***> wrote: I had a hard time bringing my board up. I ran down the default upload speeds from 1.5Mbps to 115200 because the seconds I could save weren't worth potential hours of debugging. I also found that erasing the board's flash (I used "esptool.py --chip esp32 --port /dev/cu.usbserial-101 erase_flash" but the recipe may be different for you) was helpful in getting my board otu of the weeds. Monitoring the system's boot logs (on Mesmerizer, it was the second interface) never gave me actionable data, but it was helpful to know if hte board was bootlooping because the flash write hadn't been successful, of if that had assed and it was a good time to retry the web flasher because only then did the options to configure local networking appear. I had better luck initially with the web flasher at https://plummerssoftwarellc.github.io/NightDriverStrip/ just so I KNEW the binary I was squirting to the board was a working bootable image. I sunk several hours into it. It feels like I should have found the "AHA, you forgot to configure THIS" or "move the jumper" kind of moment of clarity, but I didn't. My trip to success, such as it is, was pretty random attempts of mixing commands via esp.py, pio (which I assume wraps esp.py), and the web interface above. Good luck. — Reply to this email directly, view it on GitHub <#311 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA4HCF6IX5GWQTDJNYHCKRLXKZO5TANCNFSM6AAAAAAY6NIBHI>. You are receiving this because you are subscribed to this thread.

[cjhoffmn]

I tried one of my new ESP32s and got the same error. I futzed around with the serial port settings and none seemed to change anything. The UART bridge could only go up to 128,000 baud. I tried it with less and more buffers and flow control on and off. I do note that even if I disconnected the unit and reconnected it - until I had shut down the webpage and reloaded it - I couldn't try again.

I just loaded up PlaformIO and I'll give that a go and report back any findings.

[cjhoffmn]

Using PlatformIO, I have successfully uploaded and have the Demo running now. I have just re-flashed it after turning on the wifi etc. Before I get lost in working with that - I wanted to get this report back. At least we know this problem appears to be something between the webinstaller and my setup.

Confirming I have the DEMO up and running now and have accessed its web interface successfully.
Confirming that LEDStrip flashed OK to my esp32 and is up and running on the MC, with web access. It appears as if the PlatformIO worked where the webinstaller did not.

[cjhoffmn]

This may be a silly question - but I remembered that when I did install from PlatformIO the first time, it failed because I hadn't created secrets.h. I realized the problem, created that file and then it worked perfectly. That couldn't possibly be the problem with the webinstaller, could it? Seems unlikely, but figured I'd ask in the spirit of trying....

[rbergen]

I think it's actually a good broad-perspective question to ask, but the answer is that this isn't the issue. Part of the CI workflow that builds the images that are used by the web installer, is creating (a semi-bogus) secrets.h from a copy of secrets.example.h. If it didn't do this then none of the projects would build, and none of the web installer images would even be there.

The fact that the flash starts and then fails at 64% shows that the basic ingredients are all there, but the low-level processes of flashing, booting and then sorting out basic config for your particular board/chip are not working as they should. All of that is basically handled by libraries/components this project pulls in, which makes it incredibly difficult to debug - for me certainly without having the device in question available to me.

[cjhoffmn]

Makes sense, knew it was a shot in the dark.

Given that I've got it up and running in PlatformIO now, I don't need to worry about this anymore - but for potential future debugging, in addition to the spec info above I'll only add that it occurred on Espressif, and DEVKIT1 versions of the the esp32 (and it occurred with all versions of LEDstrip - I ultimately tested them all). I'll chalk it up to something peculiar with my laptop and the UART bridge driver for now. If I try again and get it to work, I'll post something new.

I appreciate the response @rbergen.

[rbergen]

@cjhoffmn Circling back to this, did you experience this issue (only) when trying to flash LEDStrip using the Web Installer?

I'm asking because we did identify a specific issue with web installing that project, as documented in #371. If it was this project you experienced the problem with, then I think we can close this issue in favor of the one I just mentioned.

[rbergen]

Closing this for lack of author response.