Update with curl responds with error 500 -12 write failed

adoerler commented 3 years ago

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

kurtwarwick-new commented 3 years ago

Hi

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

Regards

Kurt

kurtwarwick-new commented 3 years ago

Also, @yaourdt

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

Thank you!!!

Regards

Kurt

kurtwarwick-new commented 3 years ago

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 commented 3 years ago

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

kurtwarwick-new commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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

Diegocampy commented 3 years ago

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

sorry, I delete mi post.

yaourdt commented 3 years ago

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 - richardaburton@gmail.com
[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 - richardaburton@gmail.com
[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 commented 3 years ago

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

kurtwarwick-new commented 3 years ago

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

kurtwarwick-new commented 3 years ago

@adoerler

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

Thanks!

adoerler commented 3 years ago

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 commented 3 years ago

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

yahwehPT commented 3 years ago

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

yaourdt commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

[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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

how do I reboot while logging?

yaourdt commented 3 years ago

Use RST or cut 3V3 for a moment

yahwehPT commented 3 years ago

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

yahwehPT commented 3 years ago

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?

yaourdt commented 3 years ago

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

yaourdt commented 3 years ago

@yahwehPT @kurtwarwick-new - I may have found it. Could you or anyone interested please try the following binaries, to see if they work:

test-mode-dout.zip

yahwehPT commented 3 years ago

@yaourdt I flashed the 0x7000 and now I can't connect to wifi anymore:

Connecting....
Detecting chip type... ESP8266
Chip is ESP8266EX
Features: WiFi
Crystal is 26MHz
MAC: 
Enabling default SPI flash mode...
Configuring flash size...
Auto-detected Flash size: 2MB
Erasing flash...
Took 1.78s to erase flash block
Wrote 524288 bytes at 0x00007000 in 53.3 seconds (78.7 kbit/s)...

Leaving...
Hard resetting via RTS pin...

I used esptool to flash 0x7000.bin at 0x7000

yahwehPT commented 3 years ago

actually it's working I was writing to 0x7000 and should write to 0x0... your magic worked

yaourdt commented 3 years ago

Correct, flashing should start from address 0x0. Nice! I'll finish the fix tomorrow

yahwehPT commented 3 years ago

Can I use the test you send to flash the rest of plug-s I have or should I wait for tomorrow for an improved fix?

yahwehPT commented 3 years ago

And thank you very much!!!

yaourdt commented 3 years ago

You are welcome. You can give it a try, there is (most likely) no harm in it, but it will probably result in -12 write failed.

yaourdt commented 3 years ago

Released a new version that fixes this issue. @Diegocampy this should also fix your problems, at least for future attempts. Devices already bricked can probably not be recovered without flashing over a wired connection.

yahwehPT commented 3 years ago

same error with ota. please reopen and I will set up logging

yaourdt commented 3 years ago

can you please be more specific in what you did? device, starting firmware,...

yahwehPT commented 3 years ago

another shelly plug-s, was with tasmota 9.2.0, flashed tasmota minimal (9.2.0), flashed 0x7000 and then curl gives 500 server error.

edit: was the same setup as the other plug, and used the new 0x7000.bin (double checked)

yaourdt commented 3 years ago

can you please provide logs?

yahwehPT commented 3 years ago

[Feb  2 11:32:59.070] mgos_http_server.c:180  0x3ffefbf4 HTTP connection from 10.42.42.50:54364
[Feb  2 11:33:00.068] mgos_ota_core.c:252     Starting, timeout 600, commit timeout 0, mem 42208
[Feb  2 11:33:00.082] mgos_mongoose.c:66      New heap free LWM: 40072
[Feb  2 11:33:00.082] mgos_mongoose.c:66      New heap free LWM: 39992
[Feb  2 11:33:00.093] mgos_ota_core.c:486     FW: shelly-plug-s esp8266 1.0 20210115-103659/v1.9.4@e2732e05
[Feb  2 11:33:00.105] esp_ota_backend.c:185   Slot 1, FW: shelly-plug-s.bin -> 0x108000, FS fs.bin -> 0x1bb000
[Feb  2 11:33:00.115] mgos_ota_core.c:504     0.18% total, esp_init_data_default_v08.bin 128 of 128
[Feb  2 11:33:00.123] mgos_mongoose.c:66      New heap free LWM: 38648
[Feb  2 11:33:00.137] esp_ota_backend.c:205   Failed to read 64 bytes from 0x1bb000
[Feb  2 11:33:00.137] esp_ota_backend.c:338   Start writing fs.bin (262144) @ 0x1bb000
[Feb  2 11:33:00.151] esp_flash_writer.c:77   Erase sector 443 (0x1bb000) -> 1
[Feb  2 11:33:00.151] mgos_ota_core.c:811     Update finished, result -12 (Write failed)
[Feb  2 11:33:08.434] mgos_wifi.c:345         WiFi STA: Connect timeout
[Feb  2 11:33:08.434] mgos_wifi.c:88          WiFi STA: Using config 0 (vtrust-flash)
[Feb  2 11:33:08.434] esp_wifi.c:203          WiFi STA IP: 10.42.42.44/255.255.255.0 gw 10.42.42.1
[Feb  2 11:33:08.434] mgos_wifi.c:270         WiFi STA: Connecting to vtrust-flash
[Feb  2 11:33:08.441] mgos_net.c:86           WiFi STA: connecting
[Feb  2 11:33:11.288] esp_main.c:145          SDK: scandone
[Feb  2 11:33:11.288] mgos_wifi.c:118         WiFi STA: Disconnected, reason: 201
[Feb  2 11:33:11.288] mgos_net.c:82           WiFi STA: disconnected

yaourdt commented 3 years ago

Thanks. What did you do differently, compared to flashing the test files? The files you downloaded today are exactly the same as in test-mode-dout.zip

yaourdt commented 3 years ago

Ah, you flashed the test files using a wired connection, not OTA. Interesting. What are your esp flash params?

yahwehPT commented 3 years ago

Yes, test files where by wire, ota gave me an error, using only the .bin file the error I believe was not a zip file and and if was zipped I got another error that I will check later (away from computer) what I did was flash, by wire, using esptool (default parameters: esptool write_flash 0x0 file.bin) the 7000.bin test file and then ota worked. Today I used only OTA, maybe I should reset the plug before flashing 7000.bin?

edit: sorry using curl to upload 0x7000.bin by ota gave the error: -1 Malformed archive (invalid header)

yahwehPT commented 3 years ago

After flashing again by wire the curl command works as intended. Must be the flashing method that tasmota is doing or I wonder if this is something to do with it: Hard resetting via RTS pin... that esptool does at end of the flash.

yahwehPT commented 3 years ago

now this weird. I tryed to flash back to tasmota... and now your method doesn't work. Not the correct place to post but maybe they are connected?

[Feb  2 17:24:45.416]  ets Jan  8 2013,rst cause:1, boot mode:(3,7)
[Feb  2 17:24:45.416]
[Feb  2 17:24:45.416] load 0x40100000, len 1732, room 16
[Feb  2 17:24:45.416] tail 4
[Feb  2 17:24:45.416] chksum 0x89
[Feb  2 17:24:45.416] load 0x3ffe8000, len 832, room 4
[Feb  2 17:24:45.416] tail 12
[Feb  2 17:24:45.416] chksum 0x7c
[Feb  2 17:24:45.416] csum 0x7c
[Feb  2 17:24:45.416] rBoot v1.2.1-cesanta1-yaourdt - richardaburton@gmail.com
[Feb  2 17:24:45.416] Flash Size:   16 Mbit
[Feb  2 17:24:45.416] Flash Mode:   DOUT
[Feb  2 17:24:45.416] Flash Speed:  80 MHz
[Feb  2 17:24:45.416] rBoot Option: Big flash
[Feb  2 17:24:45.416] rBoot Option: move esp init data
[Feb  2 17:24:45.416]
[Feb  2 17:24:45.416] Moving SDK config sectors before booting.
[Feb  2 17:24:45.434] Booting rom 1 (0x108000).
[Feb  2 17:24:45.456] �bl`☻r�n♫lph��☻�↕�n��r��n|�♀l���♫l∟b�↕☻♀�|☻r�☻l�n�♀�n� ♀l`☻��r�l�l↕�♀♀♀�mode : softAP(mac address removed
[Feb  2 17:24:45.607] bcn 0
[Feb  2 17:24:45.607] del if1
[Feb  2 17:24:45.607] usl
[Feb  2 17:24:45.607] mode : null
[Feb  2 17:24:45.607] mode : sta(mac address removed)
[Feb  2 17:24:45.607] add if0
[Feb  2 17:24:45.607] sleep disable
[Feb  2 17:24:45.607] WPA2 ENTERPRISE VERSION: [v2.0] disable
[Feb  2 17:24:45.623]
[Feb  2 17:24:45.623]

after this I still have the shelly software The weird part is that this plug had tasmota by your ota method that worked flawless....

yaourdt commented 3 years ago

Ok, lets please do this step by step. The current problem is, that we cannot write the SPI flash on some devices after an OTA update, but we can read from it. Also, we can write if we flash using the esp tool.

This is most likely a problem with the binary image header or the SPI register, for my own reference: SPI API docs, binary image header format.

This is what I found (first 16 bytes of each image):

e902 020f a406 1040 0000 1040 bc06 0000 - dio esp tool
e902 030f a406 1040 0000 1040 bc06 0000 - dout esp tool

e902 030f a406 1040 0000 1040 bc06 0000 - 0x1000 dout esp tool
e902 030f ac06 1040 0000 1040 c406 0000 - 0x7000 dout esp tool

e902 fff0 a406 1040 0000 1040 bc06 0000 - rboot.bin of this firmware
e902 fff0 f005 1040 0000 1040 0806 0000 - shelly plug s rboot.bin
e901 0320 5cf4 1040 00f0 1040 000e 0000 - tasmota

I'll have to do some more tests in the next few days to figure this out. @yahwehPT - if you can flash, you should also be able to read. Can you please read the contents of your devices flash using below command (or similar) after flashing this firmware by wire:

esptool.py read_flash 0 2097152 flash_contents.bin

You can then attach it here by dragging and dropping, but you need to zip the file first, as github does not allow bin files to be uploaded.

yahwehPT commented 3 years ago

flash_contents.zip the flash after flashing 0x7000.bin by wire

Aulos commented 3 years ago

I have the same problem with Shelly Plug-S:

flash_contents.zip

yaourdt / tasmota-to-mgos

Update with curl responds with error 500 -12 write failed #3