-
-
Notifications
You must be signed in to change notification settings - Fork 113
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Upload failed (Internal Server Error) when update to version v3.5.0b2 #629
Comments
Same here. |
If the ems-esp was origially usb-flashed with a version before 27.02.2021 the partitions are to small for the new update. |
The partition sizes haven't changed? Not sure why it's not working |
See this commit, It was ems-esp v2 (esp32). But the current v 3.5.0 should also fit in min_spiffs (0x1E0000) size, is there an overhead when flashing? |
not sure, but the partition table is exactly the same so not sure why its not working. We could use the old partition table XLS and try that, or look into what has changed in the latest IDF/espressif-arduino core. Maybe we missed something |
I've tested with some GUI-Flashers and most of them do not flash the partition table or a wrong one, In GUI select ESP32 and set these files: Tested with a node-mcu32 with other partitions before. |
so we can't upgrade anymore because we don't have a usb flash tool? strange if you ask me |
@rickroetenberg You can upgrade via ota or upload if your esp32 is partitioned correctly. I don't know why you have earlier flashed a wrong partition scheme. I hoped that this tool will help people to fix the issue, which is NOT an EMS-ESP issue. If you dont want to use it, stay with 3.4.2. Not my problem. |
Sorry, it seem i have misunderstood some things. I thought the wrong partition scheme is always done by users (via usb-flash) and could not understand why a new usb-flash is now problematic.
The Tasmota flasher is much easier to handle than the espressive tool, so i've modified the tasmota flasher to use local bootloader/partitions and call it EMS-ESP-Flasher. @proddy: Or should the flasher load the partitions.bin online from here(dev) |
So are you saying that this is a BBQKees issue for some of us in that it's been partitioned wrongly? |
yes, he's using a flash tool with preset partitions that are too small for v3.5.0 |
Let's wait for BBQKees come back. IMHO: I'm not sure if we can call it an issue. His gateways comes with preflashed, working software. No promise of endless updates. |
true. BBQKees confirmed this and will be using a new method to flash the firmware on new gateways. For existing users we should provide a script (both Windows, Linux/OSX) for the CLI tools. |
@proddy Should we add a flash info, not for v3.4.2->v3.5, but maybe for 16M chips formated to 4M? (This is formated 16M): |
Yes @MichaelDvP, that'll be good to add. With a couple of recommendations
|
OK, i'll make the change. Next word for translation. |
@MichaelDvP I just tried uploading the firmware from the Github Release assets via the WebUI and experiencing the same issue. I actually think the bug is in the CI build scripts and not related to how the Gateways are flashed. I'm investigating... |
Ok. |
it was the comment from Thomas that triggered this (https://discord.com/channels/816637840644505620/816652040305901628/1022973202454032414) . Which I still can't explain... |
I don't know what was wrong in this upload. The upload routine give error 500 for all possible errors back. A size check is done on start of upload, if the error 500 is immediatly it is the size. If upload starts and error 500 comes later it is a lost/corrupt ip-package. I had this error a few times while uploading with different sorftware, a second try always works. |
I tried it a 2nd time and it worked, like you said. Weird. I'll see if I can improve the error messaging on a failed upload in UploadFileService::handleUpload(). I'll need to use the same Flasher tool as BBQKees uses. The MD5 check has been an ask for a while (#240 (comment)). I'll open a new issue so we don't forget. |
Afaik BBQKees used this tool, it loads partitions online, see here. I've forked and load from local directory depending on flash size of target, so it will work on 4M and 16M Gateways. |
That's really cool! I say either hard code the partition settings or read them from the dev repo. And then add the flasher to the EMS-ESP project, or put the executables in the script folder so others can use it. We do need to say some kind words to the original owners of the tool for re-using their code. |
I like tools that do not need a online connection. Maybe first look in the local directory and load online if this fails? This tool is very common used, i think original is the nodemcu-flasher, forked to esphome-flasher and then to tasmota-flasher. I have not checked yet how to build binaries for mac/linux, oly tested for windows. BTW: if used as commandline tool you can specify partition and bootloader, but not in the gui. |
An EMS-ESP specific upload tool for our users would be a nice idea. We should add a warning to EMS-ESP that the upload of 3.50 via the web may cause serious problems. For production uses I'm going to switch to the Espressif factory flash version, erasing those 16MB flash each time takes too long, so I can do more in parallel. |
Uploading via web is safe. The upload reports error 500 and old software stays. Only usb-flashing with wrong partition table ends up with not booting esp32, but then someone can reflash with right partitions. |
yes, then let's make a warning in the Wiki so when this comes up again (and it will) we can just point people to the FAQ |
Ok great I misread it then somewhere during my holiday. |
can't update to version v3.5.0b2, will get Upload failed (Internal Server Error). Tried different browsers without any success..
Current version v3.4.2b5
The text was updated successfully, but these errors were encountered: