Update with curl responds with error 500 -12 write failed

[adoerler]

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

[kurtdwarwick]

Hi

I am seeing the very same thing when trying to use the Shelly Dimmer 1 firmware.

Regards

Kurt

[kurtdwarwick]

Also, @yaourdt

Thank you for this firmware! It has made reverting back to stock firmware SO easy!

Thank you!!!

Regards

Kurt

[kurtdwarwick]

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

[yaourdt]

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

[kurtdwarwick]

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

[yaourdt]

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

[adoerler]

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

[yaourdt]

@Diegocampy problem is different from the Dimmer 1 problems and should be discussed in #4

[Diegocampy]

@Diegocampy problem is different from the Dimmer 1 problems and should be discussed in #4

sorry, I delete mi post.

[yaourdt]

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 :)

[yaourdt]

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...

[kurtdwarwick]

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

[kurtdwarwick]

@adoerler

If I may ask, where were able to get recovery firmware for a Shelly Dimmer from?

Thanks!

[adoerler]

Hi Kurt,

Shelly Dimmer 1: https://www.shelly-support.eu/filebase/index.php?entry/113-shelly-dimmer-recovery-firmware-1-5-10/

BR Andreas

[yaourdt]

@kurtwarwick-new no problem, and welcome back! Looking forward to the logs.

[yahwehPT]

Same problem with shelly plug S. used 0x7000 also. Any news?

[yaourdt]

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....

[yahwehPT]

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?

[yaourdt]

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

[yahwehPT]

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

[yahwehPT]

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.

[yahwehPT]

[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

[yahwehPT]

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

[yaourdt]

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.

[yahwehPT]

how do I reboot while logging?

[yaourdt]

Use RST or cut 3V3 for a moment

[yahwehPT]

Cutting 3v3 didn’t work, I lost logging... will try RST. Thanks

[yahwehPT]

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?

[ReggiePark]

@yaourdt
are you looking into this, so we don't have to use a wired connection anymore?

[niwla23]

Same problem with Shelly RGBW2 here.

[ShagoY]

Same problem with Shelly PlugS and mgos512k-0x7000.bin loaded via OTA

curl -i -F filedata=@./SHPLG-S.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

[mrbluebrett]

Same problem with Shelly PlugS and mgos512k-0x7000.bin loaded via OTA

curl -i -F filedata=@./SHPLG-S.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

Same here... Any update?

[Diegocampy]

I'll be back here now too with error 12 on Shelly Plug S. I have read everything but I did not understand if I can restore my 4 plugs.

[Diegocampy]

ok, since returning to my Shelly Plus S is impossible, does anyone know how to get back from Mongoose to tasmota?
I think with this command: curl -i -F filedata=@?????????????.zip http://10.42.42.44/update
but with which firmware?

[kstief]

I had the same problem with my Shelly Plug-S. I don´t think you are able to flash back tasmota from Mongoose via ota with this Error. You can recover your Shelly by soilder a serial adapter to Shelly and flash back the stock or the tasmota firmware with the esptool. You can find a manual here: https://github.com/qtoggle/espqtoggle/wiki/Shelly-Plug-S

[smartmatic]

I am facing also the same flashing issue with Shelly Plug S.

Is a short-term solution to the error expected?

[ReggiePark]

Is @yaourdt still alive (or interested in this)? There hasn't been any GitHub activity since early last year.

[Sillium]

I'm facing the same problem with a Shelly Plug S. If anyone knows of a workaround to at least get Tasmota back working, that would be sufficient for me.

curl -i -F filedata=@./SHPLG-S.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

[nbranquinho]

I'm facing the same problem with a Shelly Plug S. If anyone knows of a workaround to at least get Tasmota back working, that would be sufficient for me.

curl -i -F filedata=@./SHPLG-S.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

@Sillium Try do this

--> [Flash with wires] (#3 (comment) )

Someone reported that worked on the same device

--> [confirm that works on shelly plug S] (#3 (comment))

You can find the firmware 0x700 here

[pgorod]

Hi. I just got stuck on the Tasmota-back-to-Shelly-stock-firmware procedure, I am also getting this Write failed error.

So, if I am reading this correctly, there is currently no way to solve this problem for people who are not going to do the wired flashing, right? No way forward to the Shelly stock firmware, and no way back to the Tasmota, right?

:-(

[markus-barta]

Same issue here: -12 Write failed

Any update on how to get out of "Limbo" when soldering is not an option?

[Mar1usW3]

i have a shelly plug s with also the -12 Write failed error. Is there any fix?

[Armadillo1]

Trying to recover RGBW2 with 0x7000 firmware. Flashing wired, but getting this, regardless of flashing software (Tasmotizer, esptool, ESP Flasher)

C:\Users\Random\Desktop>esptool.py --chip esp8266 --port COM4 write_flash -z 0x0 mgos512k-0x7000.bin
esptool.py v4.4
Serial port COM4
Connecting...
Chip is ESP8266EX
Features: WiFi
Crystal is 26MHz
MAC: c4:5b:be:e0:c0:7c
Stub is already running. No upload is necessary.
Configuring flash size...
Flash will be erased from 0x00000000 to 0x0007ffff...
Compressed 524288 bytes to 311031...
Writing at 0x0006c74a... (100 %)
A fatal error occurred: Serial data stream stopped: Possible serial noise or corruption.

C:\Users\Random\Desktop>

[simao]

@Armadillo1 any tips opening the rgbw? Seems the only way is to break it.

[Armadillo1]

Will just repost what I've posted on reddit - perhaps we can work out how to get my RGBW2 to talk to shelly fw again.

I bought myself a Shelly RGBW2 (based on ESP8266) to control aquarium lights. However since the timers within the shelly software were quite primitive, I decided to give WLED and Tasmota a try, which was relatively easy to flash both OTA and via usb to serial adapter. I am now struggling to get back to the Shelly firmware.

What I have tried so far:

1)Flashing shelly's recovery firmware with ESPTool. It gets briefly stuck at 100% with a subsequent error:

C:\Users\Random\Desktop\RGBW_recovery_firmware_version3>esptool.py --port COM4 erase_flash
esptool.py v4.4
Serial port COM4
Connecting...
Detecting chip type... Unsupported detection protocol, switching and trying again...
Connecting...
Detecting chip type... ESP8266
Chip is ESP8266EX
Features: WiFi
Crystal is 26MHz
MAC: c4:5b:be:e0:c0:7c
Stub is already running. No upload is necessary.
Erasing flash (this may take a while)...
Chip erase completed successfully in 0.0s
Hard resetting via RTS pin...

C:\Users\Random\Desktop\RGBW_recovery_firmware_version3>esptool.py --port COM4 write_flash 0x0 RGBW_recovery.bin
esptool.py v4.4
Serial port COM4
Connecting...
Detecting chip type... Unsupported detection protocol, switching and trying again...
Connecting...
Detecting chip type... ESP8266
Chip is ESP8266EX
Features: WiFi
Crystal is 26MHz
MAC: c4:5b:be:e0:c0:7c
Stub is already running. No upload is necessary.
Configuring flash size...
Flash will be erased from 0x00000000 to 0x001fffff...
Compressed 2097152 bytes to 387054...
Writing at 0x0008cac7... (100 %)
A fatal error occurred: Serial data stream stopped: Possible serial noise or corruption.

C:\Users\Random\Desktop\RGBW_recovery_firmware_version3>
2) Tried this method: https://github.com/yaourdt/tasmota-to-mgos

With the -12 Write failed error that quite a few people seem to have (fewer with the RGBW2 that I have - some managed to update successfully).

3. Tried different combinations of flashing one firmware after another (different Tasmotas, WLED), ending with Shelly RGBW2 fw last with Tasmotizer (stops at 100% with a similar error as in 1) ).

I can still use the shelly with Tasmota, which I don't quite like or possibly ESPHome, which I haven't fully tried to flash yet.

Any ideas? Have I managed to completely screw up my shelly or is this recoverable ?

[simao]

@Armadillo1 yeah but i meant how did you open the shelle to connect to the serial pins? cant open it without breaking it. thanks

[Armadillo1]

You don't need to open. The headers are accessible from the outside. The 5 black pin holes at the top.

[simao]

Uh damn it, I misread this and thought you had a shelly RGBW bulb. Sorry for the confusion.

[agofi]

Same problem with ShellyPlugS and mgos512k-0x7000.bin loaded via OTA

Loaded same mgos512k-0x7000.bin with Tasmotizer: working!

It worked also for me!
loaded the mgos512k-0x7000.bin with Tasmotizer, not need to solder anything, the pins are reachable just removing the upper cover. You have only to find a way to keep in place the pins during flashing procedure..
for opening shelly plug see here.. (There is a screw hidden inside the earth plug)
for shelly plug pinout see here.
after loading mgos512k-0x7000.bin with Tasmotizer you can send update using CURL (curl -i -F filedata=@./fw.zip http://10.42.42.44/update).

hope it helps!

[TBR-BRD]

I can not download https://dl.dasker.eu/firmware/mgos512k-0x7000.bin
Do you have a working source? Thank you

[nbranquinho]

I believe that exists a problem with server. I uploaded temporarily to send to you.
mgos512k-0x7000.zip

[TBR-BRD]

I believe that exists a problem with server. I uploaded temporarily to send to you. mgos512k-0x7000.zip

Thank you for your help! Unfortunately it did not work, there is then an http response error. I then took the direct route and flashed a Shelly firmware.

[TBR-BRD]

Firmware: https://www.shelly-support.eu/forum/thread/444-anleitung-firmware-flashen-mit-espeasy-flasher-alle-firmware-bin-dateien-windows/?postID=182323#post182323
direct: https://www.shelly-support.eu/attachment/35600-shelly-plug-s-20200317-143422-v1-6-1-112262fd-bin-zip/
flash with USB serial adapter
Shelly App add device
Firmware update in the App
it works!!! Shelly Plug S with newest firmware

[TBR-BRD]

flash without soldering

[henriec]

Firmware: https://www.shelly-support.eu/forum/thread/444-anleitung-firmware-flashen-mit-espeasy-flasher-alle-firmware-bin-dateien-windows/?postID=182323#post182323
direct: https://www.shelly-support.eu/attachment/35600-shelly-plug-s-20200317-143422-v1-6-1-112262fd-bin-zip/
flash with USB serial adapter
Shelly App add device
Firmware update in the App
it works!!! Shelly Plug S with newest firmware

Thanks a Lot!!!!! This is the only working solution I could find! I'm happy!

[hnykda]

Just wanted to share with others that I am unable to get back to Shelly Stock firmware on RGBW2. The classic -12 Write Failed error... So, for those who want to know if they can easily (that is via OTA) get back to stock on RGBW2 - don't.