Open adoerler opened 3 years ago
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 - 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 :)
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.
Same problem with shelly plug S. used 0x7000 also. Any news?
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.
how do I reboot while logging?
Use RST or cut 3V3 for a moment
Cutting 3v3 didn’t work, I lost logging... will try RST. Thanks
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:
@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
actually it's working I was writing to 0x7000 and should write to 0x0... your magic worked
Correct, flashing should start from address 0x0. Nice! I'll finish the fix tomorrow
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?
And thank you very much!!!
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
.
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.
same error with ota. please reopen and I will set up logging
can you please be more specific in what you did? device, starting firmware,...
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)
can you please provide logs?
[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
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
Ah, you flashed the test files using a wired connection, not OTA. Interesting. What are your esp flash params?
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)
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.
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....
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.
flash_contents.zip the flash after flashing 0x7000.bin by wire
I have the same problem with Shelly Plug-S:
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:
But curl responds with
I'm using this firmware
http://shelly-api-eu.shelly.cloud/firmware/SHDM-1.zip
.Did I miss something?
Best regards\ Andreas