[Bug] Board crashes when loading captive portal

[redmushie]

Pre-submission checklist

• [X] I checked that no other Bug Report describing my problem exists.
• [X] I am running the latest stable or prerelease firmware.
• [X] My board is on the list of maintained boards.
• [X] I accept that this issue may be closed if any of the above are found to be untrue.

Board

Pishock 2023

Firmware version

1.0.0-rc.2

Flashing method

I used esptool write_flash 0x0 <image>

Describe what happened as precisely as possible.

When connecting to the captive wifi network and trying to load the captive portal, the board crashes, and the page doesn't finish loading:

After 1 attempt:

Then, reconnecting to the wifi network (since it crashed), trying to load it again:

The board crashes again.

Serial monitor logs:

Describe what you expected to happen instead.

Captive portal should load without the board crashing and the wifi connection dropping as a result.

In as much detail as possible, describe the exact steps you took to make the problem appear.

1. Connect to OpenShock wifi network
2. Visit http://10.10.10.10/
3. (The board crashes while the page is loading)

Other remarks

No response

[LucHeart]

Caused by the icon font being too large, CI seems to not strip the icon font used. Works with local build cause the stripping works there.

[redmushie]

Interesting. I could probably fix this myself then.

[hhvrc]

@LucHeart @redmushie This should be fixed with the latest PR merge

[redmushie]

@hhvrc Bet, I'll test it right now

[redmushie]

Nope, still happens :(

[LucHeart]

can easily verify by looking at build artifacts, captive portal, icon font should not be 130kb

[LucHeart]

*150Kb even

[redmushie]

@LucHeart That doesn't hold up -- the captive-portal artifact is produced by the build-captive-portal CI step, which is prior to the optimization done by the build-filesystem step.

[redmushie]

Did a quick test:

I don't think the font is the issue. (This gets gzipped after, too!)

[redmushie]

I think it's most likely a js file that's largest.

Some more logging statements:

Regardless, is [a large file] really the problem that we need to fix? There should be plenty other ways to approach this problem.

• Find a way to give the ESP some breathing room between serving a ton of assets
• Increase WDT timeout duration if possible
• Disable WDT timeout (oof)
• ...

[hhvrc]

@LucHeart @redmushie This is tested to be a issue due to voltage drop when high current is pulled.

This occurs when the board tries to do some intensive workload like serving alot of files at once.

This voltage drops below the CPU's operating voltage causing it to crash.

Note: this is a hypothesis but tests seems to confirm it.

[LucHeart]

note: it does not report a brownout...

[hhvrc]

That's true, but changing the power supply source significally decreases the likelyhood of a crash occuring, this has been tested on 3 seperate units.

I might be wrong in this being purely due to current draw, but a better power supply is tested to improve the reliability by a decent amount.

[LucHeart]

Still happens to me on a charger...

[hhvrc]

This seems like a hard problem to fix... What I can do is to manually implement the Stream that streams the file from FS to http and trigger the WDT_RESET from there, this would keep it from crashing. Temporary fix but should work. So I read 4kb from file, trigger WDT_RESET, write to http stream, WDT_RESET, repeat...

edit: I've tried both setting the WDT timeout and cancelling the WDT alltogether, none of these work, causes the board to crash