tasmota-to-mgos
tasmota-to-mgos copied to clipboard
yaourdt
Update with curl responds with error 500 -12 write failed
Hi,
thanks for providing this OTA helper. Switching to tasmota worked like a charm. I'm trying to revert back to stock firmware of a Shelly Dimmer 1.
The intermediate firmware was flashed successfully and I can access it via http which returns:
Index of
Name | Modified | Size
hwinfo_struct.json | 01-Jan-1970 00:00 | 112
conf0.json | 01-Jan-1970 00:00 | 3
Mongoose/6.18
But curl responds with
curl -i -F filedata=@./SHDM-1.zip http://10.42.42.44/update
HTTP/1.1 500 Internal Server Error
Server: Mongoose/6.18
Content-Type: text/plain
Connection: close
-12 Write failed
I'm using this firmware http://shelly-api-eu.shelly.cloud/firmware/SHDM-1.zip.
Did I miss something?
Best regards
Andreas
Hi
I am seeing the very same thing when trying to use the Shelly Dimmer 1 firmware.
Regards
Kurt
Also, @yaourdt
Thank you for this firmware! It has made reverting back to stock firmware SO easy!
Thank you!!!
Regards
Kurt
Hi again
I just wanted to update this thread to say that it doesn’t seem like I am able to flash any firmware. Not just the Shelly firmware.
Regards
Kurt
Sorry for my late reply. Did you use the 0x1000 or 0x7000 firmware for reverting? Can you please unplug the device with intermediate firmware, plug it back in again and try to write again? Do you have the possibility to attach a serial debugger, so we can get some logs?
I'll try to test the Dimmer 1 on a dev board later this week
Hi @yaourdt
No worries about the delay.
I have used 0x7000 on my devices. I have 4 of them, and all of them have flashed without failure to the intermediate firmware, but all of them are unable to flash any other firmware, even after a power cycle (as suggested above).
I am not able to attach a serial debugger at the moment. But I might be able to take one off of the light circuit and try it that way.
Regards
Kurt
Hi @kurtwarwick-new
Attaching the debugger would be a great help to see if all the preparation steps work as intended. The intermediate firmware tries to detect the devices flash size and adapt the image to it. Then, rboot moves the system config during the next restart. This has to work before you can upload the final firmware, and it may work on my dev-board, but not on your actual dimmer, so some data from an actual device would be very helpful.
Nonetheless, I'll try to reproduce it on the dev board as well as soon as I get to it
Best,
Mark
Hi Mark, hi Kurt,
i've used the 0x7000 too, as stated in your description.
After my wife complained about sleeping with lights on I had to remove the shelly anyway :-)
Unfortunately I could not get any useful output on serial console... After fiddling around I've found out that the pinout from official website is wrong (here is the correct one). Nevertheless it could not be flashed on my laptop, even when using external power supply. Later I've managed to flash it from another laptop using the Shelly recovery firmware. After flash succeeded the md5 sums did not match. For now my Dimmer 1 is in a dead state and I've ordered a Shelly Dimmer 2 as replacement. The reason I've had to switch back, is that dimming experience with Tasmoata was not satisfying.
Sorry, I can not give any new debugging output for now.
BR Andreas
@Diegocampy problem is different from the Dimmer 1 problems and should be discussed in #4
@Diegocampy problem is different from the Dimmer 1 problems and should be discussed in #4
sorry, I delete mi post.
Ok, I had a look at this issue, and for me Dimmer 1 is not working either. The problem however seems to be different. Applying the ZIP works as expected
curl -i -F filedata=@./SHDM-1.zip http://10.42.42.44/update
HTTP/1.1 200 OK
Server: Mongoose/6.18
Content-Type: text/plain
Connection: close
1 Update applied, rebooting
but the boot process hangs while booting the new rom
[Jan 14 11:23:15.591] mgos_http_server.c:180 0x3ffef85c HTTP connection from 10.42.42.50:56664
[Jan 14 11:23:16.677] mgos_ota_core.c:252 Starting, timeout 600, commit timeout 0, mem 40140
[Jan 14 11:23:16.920] mgos_mongoose.c:66 New heap free LWM: 37984
[Jan 14 11:23:16.927] mgos_mongoose.c:66 New heap free LWM: 37104
[Jan 14 11:23:16.931] mgos_mongoose.c:66 New heap free LWM: 36888
[Jan 14 11:23:16.941] mgos_ota_core.c:486 FW: dimmer esp8266 1.0 20201228-093108/v1.9.3@ad2bb4e3
[Jan 14 11:23:16.951] esp_ota_backend.c:185 Slot 1, FW: dimmer.bin -> 0x108000, FS fs.bin -> 0x1bb000
[Jan 14 11:23:17.186] esp_ota_backend.c:338 Start writing dimmer.bin (580608) @ 0x108000
[Jan 14 11:23:17.194] mgos_mongoose.c:66 New heap free LWM: 35736
[Jan 14 11:23:17.229] mgos_ota_core.c:504 0.22% total, dimmer.bin 512 of 580608
[Jan 14 11:23:17.406] mgos_mongoose.c:66 New heap free LWM: 35720
[Jan 14 11:23:18.165] mgos_mongoose.c:66 New heap free LWM: 35592
[Jan 14 11:23:19.907] mgos_mongoose.c:66 New heap free LWM: 35480
[Jan 14 11:23:22.252] mgos_ota_core.c:504 17.50% total, dimmer.bin 146944 of 580608
[Jan 14 11:23:24.874] mgos_mongoose.c:66 New heap free LWM: 33704
[Jan 14 11:23:25.819] mgos_mongoose.c:66 New heap free LWM: 33592
[Jan 14 11:23:26.010] mgos_ota_core.c:504 48.44% total, dimmer.bin 409088 of 580608
[Jan 14 11:23:28.313] esp_ota_backend.c:376 Write finished, checksum ok
[Jan 14 11:23:28.325] mgos_ota_core.c:504 68.71% total, esp_init_data_default_v08.bin 128 of 128
[Jan 14 11:23:28.436] esp_ota_backend.c:338 Start writing fs.bin (262144) @ 0x1bb000
[Jan 14 11:23:28.498] mgos_ota_core.c:504 68.77% total, fs.bin 512 of 262144
[Jan 14 11:23:31.913] esp_ota_backend.c:376 Write finished, checksum ok
[Jan 14 11:23:31.924] mgos_ota_core.c:504 99.72% total, rboot.bin 512 of 2320
[Jan 14 11:23:31.938] mgos_ota_core.c:630 Reached the end of archive
[Jan 14 11:23:31.941] esp_ota_backend.c:410 Resetting RF calibration data @ 0x1fb000
[Jan 14 11:23:32.029] esp_ota_backend.c:442 New rboot config: prev_rom: 0, current_rom: 1 current_rom addr: 0x108000, current_rom size: 580608, current_fs addr: 0x1bb000, current_fs size: 262144
[Jan 14 11:23:32.044] mgos_ota_core.c:811 Update finished, result 1 (Update applied, rebooting)
[Jan 14 11:23:32.054] mgos_ota_core.c:853 Update requires reboot
[Jan 14 11:23:32.056] mgos_system.c:58 Rebooting in 500 ms
[Jan 14 11:23:32.562] mgos_vfs.c:1026 Unmounting filesystems
[Jan 14 11:23:32.566] esp_main.c:158 SDK: station: 14:7d:da:a9:91:4d leave, AID = 1
[Jan 14 11:23:32.572] esp_main.c:158 SDK: rm 1
[Jan 14 11:23:32.575] esp_main.c:158 SDK: bcn 0
[Jan 14 11:23:32.577] esp_main.c:158 SDK: del if1
[Jan 14 11:23:32.584] esp_main.c:158 SDK: del if0
[Jan 14 11:23:32.587] esp_main.c:158 SDK: usl
[Jan 14 11:23:32.589] esp_main.c:158 SDK: mode : null
[Jan 14 11:23:32.592] mgos_system.c:43 Restarting
[Jan 14 11:23:32.595] ets Jan 8 2013,rst cause:2, boot mode:(3,7)
[Jan 14 11:23:32.601]
[Jan 14 11:23:32.601] load 0x40100000, len 1732, room 16
[Jan 14 11:23:32.604] tail 4
[Jan 14 11:23:32.604] chksum 0x89
[Jan 14 11:23:32.604] load 0x3ffe8000, len 832, room 4
[Jan 14 11:23:32.610] tail 12
[Jan 14 11:23:32.610] chksum 0x7c
[Jan 14 11:23:32.610] csum 0x7c
[Jan 14 11:23:32.613] rBoot v1.2.1-cesanta1-yaourdt - [email protected]
[Jan 14 11:23:32.616] Flash Size: 32 Mbit
[Jan 14 11:23:32.619] Flash Mode: DOUT
[Jan 14 11:23:32.622] Flash Speed: 80 MHz
[Jan 14 11:23:32.622] rBoot Option: Big flash
[Jan 14 11:23:32.624] rBoot Option: move esp init data
[Jan 14 11:23:32.629]
[Jan 14 11:23:32.629] Moving SDK config sectors before booting.
[Jan 14 11:23:32.774] First boot, attempt 0
[Jan 14 11:23:32.774] Boot is unconfirmed
[Jan 14 11:23:32.828] Booting rom 1 (0x108000).
[Jan 14 11:23:32.850] cl { n d
[Jan 14 11:23:33.452]
[Jan 14 11:23:33.517] ets Jan 8 2013,rst cause:2, boot mode:(3,7)
[Jan 14 11:23:33.520]
[Jan 14 11:23:33.520] load 0x40100000, len 1732, room 16
[Jan 14 11:23:33.523] tail 4
[Jan 14 11:23:33.526] chksum 0x89
[Jan 14 11:23:33.526] load 0x3ffe8000, len 832, room 4
[Jan 14 11:23:33.529] tail 12
[Jan 14 11:23:33.529] chksum 0x7c
[Jan 14 11:23:33.532] csum 0x7c
[Jan 14 11:23:33.532] rBoot v1.2.1-cesanta1-yaourdt - [email protected]
[Jan 14 11:23:33.538] Flash Size: 32 Mbit
[Jan 14 11:23:33.541] Flash Mode: DOUT
[Jan 14 11:23:33.541] Flash Speed: 80 MHz
[Jan 14 11:23:33.544] rBoot Option: Big flash
[Jan 14 11:23:33.546] rBoot Option: move esp init data
[Jan 14 11:23:33.550]
[Jan 14 11:23:33.550] Moving SDK config sectors before booting.
[Jan 14 11:23:33.572] Booting rom 1 (0x108000).
[Jan 14 11:23:33.594] #d` ; o l
[Jan 14 11:23:33.883] ^C
there is no difference between the release and beta firmware. Testing other variants such as the Shelly Plug S (SHPLG-S.zip) works as expected, so this is most likely a device specific problem.
The 500 / -12 Write failed error message indicates a problem with writing to a certain flash location. I'll try to investigate further, but if any one of you @kurtwarwick-new or @adoerler could contribute some actual device logs, this would help a lot :)
I tried newer mos versions now, 2.18.0 and 2.19.0, and the error remains the same. Maybe the dev boards flash size (32 Mbit instead of 16Mbit in the Shelly) leads to the issue. What we can see from the logs is that the Shelly stock firmware will load initially and confirm the boot, but fails after the first reboot:
[Jan 14 11:23:32.629] Moving SDK config sectors before booting.
[Jan 14 11:23:32.774] First boot, attempt 0
[Jan 14 11:23:32.774] Boot is unconfirmed
[Jan 14 11:23:32.828] Booting rom 1 (0x108000).
vs second try with confirmed boot
[Jan 14 11:23:33.550] Moving SDK config sectors before booting.
[Jan 14 11:23:33.572] Booting rom 1 (0x108000).
Still, this is further than where you got. I'll have to wait for you providing me with logs...
Hi @yaourdt
Apologies for being MIA. I have been on vacation for the past 2 weeks.
I will attach a debugger to one of my Shelley’s and send the output as soon as I can!
Thanks so much for attempting none-the-less!
Regards
Kurt
@adoerler
If I may ask, where were able to get recovery firmware for a Shelly Dimmer from?
Thanks!
Hi Kurt,
Shelly Dimmer 1: https://www.shelly-support.eu/filebase/index.php?entry/113-shelly-dimmer-recovery-firmware-1-5-10/
BR Andreas
@kurtwarwick-new no problem, and welcome back! Looking forward to the logs.
Unfortunately not, no. Still waiting on someone to provide logs, please feel free to contribute. I think the problem is in a closed-source part of Mongoose OS, but I don't have an answer from the maintainers yet. I'll ask them again as soon as I've seen some logs....
i could help but need some pointers. I can connect the device by pins, no problem, already tested. the problem is with 3.3v the wifi is not ready for me to connect. How do I do it to have the log?
If you can connect to the pins, you are almost there. Besides 3V3 and GND, you only need to connect RX and TX to a UART board:
UART ESP
Rx <--> Tx
Tx <--> Rx
Gnd <--> Gnd
Any software that can read from a serial output should do, I myself use the official mos tool recommended for Mongoose development.
After setting it all up, just run mos console in a terminal and logs should start coming in. mos ports will list all available serial ports if you have more than one. In this case use mos console --port /path/to/port for connecting to the device
Thank you, but my problem wasn’t that. After doing all that I don’t see any wifi network to connect and try ota update
actually... nevermind that, I'm just stupid. I was grounding GPIO0, putting in programming mode, so no wifi.... can we turn back time? in my defence I usually do that when flashing by cable. will get the logs ASAP. thank you again.
[Jan 28 11:37:51.520] mgos_http_server.c:180 0x3fff0d54 HTTP connection from 10.42.42.51:50607
[Jan 28 11:37:52.632] mgos_ota_core.c:252 Starting, timeout 600, commit timeout 0, mem 42176
[Jan 28 11:37:52.632] mgos_ota_core.c:486 FW: shelly-plug-s esp8266 1.0 20210115-103659/v1.9.4@e2732e05
[Jan 28 11:37:52.632] esp_ota_backend.c:185 Slot 1, FW: shelly-plug-s.bin -> 0x108000, FS fs.bin -> 0x1bb000
[Jan 28 11:37:52.632] mgos_ota_core.c:504 0.18% total, esp_init_data_default_v08.bin 128 of 128
[Jan 28 11:37:52.632] mgos_mongoose.c:66 New heap free LWM: 38848
[Jan 28 11:37:52.632] esp_ota_backend.c:205 Failed to read 64 bytes from 0x1bb000
[Jan 28 11:37:52.632] esp_ota_backend.c:338 Start writing fs.bin (262144) @ 0x1bb000
[Jan 28 11:37:52.632] esp_flash_writer.c:76 Erase sector 443 (0x1bb000) -> 1
[Jan 28 11:37:52.632] mgos_ota_core.c:811 Update finished, result -12 (Write failed)
[Jan 28 11:37:52.632] mgos_mongoose.c:66 New heap free LWM: 38576
[Jan 28 11:37:58.218] mgos_wifi.c:345 WiFi STA: Connect timeout
[Jan 28 11:37:58.218] mgos_wifi.c:88 WiFi STA: Using config 0 (vtrust-flash)
[Jan 28 11:37:58.218] esp_wifi.c:201 WiFi STA IP: 10.42.42.44/255.255.255.0 gw 10.42.42.1
[Jan 28 11:37:58.218] mgos_wifi.c:270 WiFi STA: Connecting to vtrust-flash
[Jan 28 11:37:58.218] mgos_net.c:86 WiFi STA: connecting
--- yaourdt edit: format code
leaving logging on I'm getting this:
[Jan 28 11:38:28.243] mgos_wifi.c:345 WiFi STA: Connect timeout
[Jan 28 11:38:28.243] mgos_wifi.c:88 WiFi STA: Using config 0 (vtrust-flash)
[Jan 28 11:38:28.243] esp_wifi.c:201 WiFi STA IP: 10.42.42.44/255.255.255.0 gw 10.42.42.1
[Jan 28 11:38:28.243] mgos_wifi.c:270 WiFi STA: Connecting to vtrust-flash
[Jan 28 11:38:28.243] mgos_net.c:86 WiFi STA: connecting
[Jan 28 11:39:34.238] esp_main.c:158 SDK: scandone
[Jan 28 11:39:34.238] mgos_wifi.c:118 WiFi STA: Disconnected, reason: 201
[Jan 28 11:39:34.238] mgos_net.c:82 WiFi STA: disconnected
[Jan 28 11:39:34.238] mgos_wifi.c:345 WiFi STA: Connect timeout
[Jan 28 11:39:34.238] mgos_wifi.c:88 WiFi STA: Using config 0 (vtrust-flash)
[Jan 28 11:39:34.238] esp_wifi.c:201 WiFi STA IP: 10.42.42.44/255.255.255.0 gw 10.42.42.1
[Jan 28 11:39:34.238] mgos_wifi.c:270 WiFi STA: Connecting to vtrust-flash
[Jan 28 11:39:34.238] mgos_net.c:86 WiFi STA: connecting
[Jan 28 11:39:34.238] esp_main.c:158 SDK: scandone
[Jan 28 11:39:34.238] mgos_wifi.c:118 WiFi STA: Disconnected, reason: 201
[Jan 28 11:39:34.238] mgos_net.c:82 WiFi STA: disconnected
[Jan 28 11:39:34.238] mgos_wifi.c:345 WiFi STA: Connect timeout
[Jan 28 11:39:34.238] mgos_wifi.c:88 WiFi STA: Using config 0 (vtrust-flash)
[Jan 28 11:39:34.238] esp_wifi.c:201 WiFi STA IP: 10.42.42.44/255.255.255.0 gw 10.42.42.1
[Jan 28 11:39:34.238] mgos_wifi.c:270 WiFi STA: Connecting to vtrust-flash
[Jan 28 11:39:34.238] mgos_net.c:86 WiFi STA: connecting
[Jan 28 11:39:34.238] esp_main.c:158 SDK: scandone
[Jan 28 11:39:34.238] mgos_wifi.c:118 WiFi STA: Disconnected, reason: 201
[Jan 28 11:39:34.238] mgos_net.c:82 WiFi STA: disconnected
[Jan 28 11:39:58.324] mgos_wifi.c:345 WiFi STA: Connect timeout
[Jan 28 11:39:58.324] mgos_wifi.c:88 WiFi STA: Using config 0 (vtrust-flash)
[Jan 28 11:39:58.324] esp_wifi.c:201 WiFi STA IP: 10.42.42.44/255.255.255.0 gw 10.42.42.1
[Jan 28 11:39:58.324] mgos_wifi.c:270 WiFi STA: Connecting to vtrust-flash
[Jan 28 11:39:58.324] mgos_net.c:86 WiFi STA: connecting
Thanks! esp_ota_backend.c is part of the closed source updating mechanism, but esp_flash_writer.c is open source.
I have to dig in a bit, but what I can say for now: The addresses calculated (FW: shelly-plug-s.bin -> 0x108000, FS fs.bin -> 0x1bb000) are correct for a 2M system. Still spi_flash_erase_sector@esp_flash_writer.c:76 throws the error code SPI_FLASH_RESULT_ERR (= 1) which is then turned into code -12 by the wrapping function.
Could you please also post the boot parameters starting from ets Jan 8 2013,rst cause:2, boot mode:(3,7) ? You can use the <> symbol to format what you are posting as code.
can't reboot and log. Most of the time I get an access denied when using this adaptor with bad drivers (the ones I found). works fine with tasmonizer but the rest..... It's a Prolific PL2303HX . Using mos.exe gui has an option to reboot, but always access denied. when using "mos call RST" access denied. any ideas?
I cannot help you with Windows issues, sorry. A short Google Search turned up this resource which explains the RST pin on the eps8266 a bit more in detail: https://randomnerdtutorials.com/esp8266-pinout-reference-gpios/ - basically, pull the RST pin low for a moment to reset. This should not interrupt console output
@yahwehPT @kurtwarwick-new - I may have found it. Could you or anyone interested please try the following binaries, to see if they work: