Boot Loop After flashing

[tommibru]

Describe the bug
After flashing a previously flashed esp home panel, the screen goes into a boot loop. i have tried going back to esp home and it works.

Due to the boot loop that feels like a constant rebooting I cannot even get to the wifi to connect to the panel and link it to the manager.

Has this happened to anyone else or am I maybe doing something wrong?

Thank you.

[tpanajott]

We've seen similar issues with other people. Are you trying to run stable or beta?

[tommibru]

Im using the beta nspanelmanager on home assistant.

But as far as .bin file I'm using the marged_flash.bin found inside the docker/web/ folder.

Is there maybe a different bin file I should be using/trying?

[tpanajott]

No, that is the correct one given you downloaded it from the "beta" branch? If not, try that. If that is indeed the file you've downloaded send over the logs it spits out when it reboots. Chapter 5 in the manual describes the procedure to capture the logs over serial.

[tommibru]

Will test the beta and also pull the logs.

Thank you.

[tommibru]

Pardon my ignorance, where can I find the other .bin file? I can only find one.
I also am not sure if the one i have uploaded is the beta or stable.

[tpanajott]

Switch the branch out to the left. Here's a direct link: https://github.com/NSPManager/NSPanelManager/tree/beta/docker/web/nspanelmanager

[tommibru]

logs.txt
Thank you for pointing out where to look. I tried the beta and same thing is happening.

Attached the log file.

[tpanajott]

Thanks. I'll try and rake a look at it. In the mean time, do you happen to have the specific TFT file that you have flashed to it currently? I believe that's where the issue is.

[tommibru]

Correct I have a tft file on it.
Is there a way I can remove it?

[tpanajott]

It's possible to solder wires to test pads and flash a new file via the software that is used to create them. But I would really appreciate to get my hands on the file you have on it. That way I can solve this so it hopefully doesn't happen again for someone else.

[flo269]

We are facing the exact same here at the moment. We had been using this https://github.com/Blackymas/NSPanel_HA_Blueprint. We used our own tft and now reflashed this one here: https://github.com/Blackymas/NSPanel_HA_Blueprint/blob/main/hmi/nspanel_eu.tft

Using stable.

[flo269]

We just had the following idea: flashing your tft with esphome. Then try the NSPanelmanager install according to the manual. Uploading at the moment. Will give update asap.

[tpanajott]

We just had the following idea: flashing your tft with esphome. Then try the NSPanelmanager install according to the manual. Uploading at the moment. Will give update asap.

I know people have done that previously. Thanks for sending over the TFT though. This shouldn't be necessary.

[tommibru]

We are facing the exact same here at the moment. We had been using this https://github.com/Blackymas/NSPanel_HA_Blueprint. We used our own tft and now reflashed this one here: https://github.com/Blackymas/NSPanel_HA_Blueprint/blob/main/hmi/nspanel_eu.tft

Using stable.

I was using the same as well and using the US version of the .tft

[tommibru]

We just had the following idea: flashing your tft with esphome. Then try the NSPanelmanager install according to the manual. Uploading at the moment. Will give update asap.

I know people have done that previously. Thanks for sending over the TFT though. This shouldn't be necessary.

Maybe the .tft takes away too much space for nspanelmanager to fully boot?

[tpanajott]

We just had the following idea: flashing your tft with esphome. Then try the NSPanelmanager install according to the manual. Uploading at the moment. Will give update asap.

I know people have done that previously. Thanks for sending over the TFT though. This shouldn't be necessary.

Maybe the .tft takes away too much space for nspanelmanager to fully boot?

They are two different microprocessor so I wouldn't think that. My suspicion is that the HA Blueprint sends something in boot that our firmware doesn't like.

[tommibru]

We just had the following idea: flashing your tft with esphome. Then try the NSPanelmanager install according to the manual. Uploading at the moment. Will give update asap.

I know people have done that previously. Thanks for sending over the TFT though. This shouldn't be necessary.

Maybe the .tft takes away too much space for nspanelmanager to fully boot?

They are two different microprocessor so I wouldn't think that. My suspicion is that the HA Blueprint sends something in boot that our firmware doesn't like.

they also have a blank.tft file

I will now re flash esp home, update to teh blank tft file then re try flashing with NSPM.

I will keep you updated.

[flo269]

We just had the following idea: flashing your tft with esphome. Then try the NSPanelmanager install according to the manual. Uploading at the moment. Will give update asap.

So this worked!

We had previously also tryied the blank file and it didn't work.

[aaronouthier]

logs.txt Thank you for pointing out where to look. I tried the beta and same thing is happening.

Attached the log file.

I'm no programmer, but the unit seems to reboot shortly after this line in the attached log file:
E (347) psram: PSRAM ID read error: 0xffffffff

That seems to be part of the issue? Without a boot log from a working bootup to compare, I can't say for sure.

[tpanajott]

logs.txt Thank you for pointing out where to look. I tried the beta and same thing is happening.

Attached the log file.

I'm no programmer, but the unit seems to reboot shortly after this line in the attached log file:
E (347) psram: PSRAM ID read error: 0xffffffff

That seems to be part of the issue? Without a boot log from a working bootup to compare, I can't say for sure.

Sure looks suspicious, the big question is why it tries to do that with that TFT file and not our.

[aaronouthier]

If the PSRAM id is read from the TFT, then the ESP home tft file might be setting a nonstandard value, which is confounding your firmware. Just a hunch.

[tommibru]

We just had the following idea: flashing your tft with esphome. Then try the NSPanelmanager install according to the manual. Uploading at the moment. Will give update asap.

So this worked!

We had previously also tryied the blank file and it didn't work.

confirming it didn't work for me either.

[aaronouthier]

I have an unused NSPanel which has never been installed. I flashed NSPanel a while back, but the TFT firmware should be stock. That said, I do have 2 different NSPanels, and may have confused/switched them without realizing it.

I am attaching the log from my boot, but it looks largely the same.
log.txt

[tommibru]

Okay...
I got it to work and successfully flash NSPM.

Steps Taken:

• Flashed NSPanel HA Blueprint
• From the developer tools > service look for ESPHome: (nameofthepanel)_upload_tft
• add the url of the nspmanager.tft (I uploaded it on Home Assistant under the WWW folder)
• Call Service(wait for tft file to upload)
• Flash the NSPM on the panel

It will boot

[aaronouthier]

@tpanajott Just a thought: Is there a way to compile firmware for the main NSPanel portion (non-tft) that will basically relay serial data to the TFT panel firmware chip, allowing one to write this special firmware first, then use the serial port without grounding the io0 port to directly write the TFT file over the serial pins, then poweroff? One could then again ground the io0 port and rewrite the normal NSPanelManager firmware.

Perhaps a bit drastic, but until a better solution is found, this might be needed?

[tpanajott]

So, a bit of an update. There were two bugs that happened to coincide.

1. When using the HA Blueprint TFT file it sends out a ton of data. Some of the data begin with values that we use to communicate from the TFT screen to the ESP32 firmware that, for example, a touch event happened. When that happens the firmware on the ESP32 expects more data to follow and we did not have a bounds check. This caused the firmware to read outside of the captured data and caused a "Load Prohibited" crash of the ESP32 causing it to reboot.
2. When the NSPanel component of the code indicates that it failed to initialize the TFT screen properly (a proper indicator is when the TFT file sends the text "NSPM" on boot to indicate that baud rate is correct and our TFT file is loaded). When the screen failed to initialize we do not load the config from the manager as there is no point. In doing so (not loading the config) the firmware later tries to access the "current room" when updating values on the pages on screen. This also caused the firmware to crash.

Both of the issues above have been fixed in the attached firmware files for the BETA version. The "stable" version is no longer supported and we will not be updating that. If any of you still have problems please give them a try. I've attached both the merged_flash.bin that you use to flash the full firmware (partition table, firmware and LittleFS) to the panel over serial. I've also attached an update firmware.bin that you may use via the "Upload" -> "Firmware" menu in the manager. This is so that you don't update the firmware on the panels and the same problem happens.

firmware_update.zip

Thank you for reporting the bug, it sure was a bit of a hunt to find the actual problem. Good thing it hopefully won't happen again. I am currently flashing our TFT OTA to the panel which was running the HA Blueprint TFT.

[cablesandcoffee]

Woo impressive job Tim! :)