Espeasy: CRC : Settings CRC ...FAIL

Created on 18 Apr 2018  Ā·  55Comments  Ā·  Source: letscontrolit/ESPEasy

While doing something else I noticed this, thought posting may help
CRC : Settings CRC ...FAIL
Was introduced between
ESP_Easy_mega-20180403_normal_ESP8266_1024.bin <- CRC : Settings CRC ...OK
&
ESP_Easy_mega-20180405_normal_ESP8266_1024.bin <- CRC : Settings CRC ...FAIL
I used a 'Save' command from serial..
Then cold booted, the same message "CRC : Settings CRC ...FAIL"

Build Settings Bug

Most helpful comment

Well, I really need nerd-stuff like this to keep my mind together, so as long as this project goes well, the rest will also follow :)

At least now, I can relax a bit more, since there is now media coverage and a lot more people actively involved in getting this process going.
So now there is more time for preparing the best possible house automation system for our new house :)

All 55 comments

The following happened between those two releases:

Commits on Apr 5, 2018

  • new #formats …
  • ESP CPU speed and ID
  • Merge pull request #1 from letscontrolit/mega …
  • modified float() call

Commits on Apr 4, 2018

  • ESP32 RTOS 10 per second …
  • ESP32 RTOS config setting
  • Merge pull request #1175 from Grovkillen/Fix-parsing-structure-for-JS… …
  • Merge pull request #1218 from soif/Fix/PioConfTypo …
  • Merge pull request #1217 from soif/Feat/JsonLoad …
  • [Wifi] Use statemachine to move between Wifi states …

I think the global "UseRTOSMultitasking" is causing this error report since the CRC check is done on build and this new settings variable has not been included in this build check (I think?).

Close #1255 as well when this is fixed.

When you save the settings, the CRC will be computed again and stored and after that it should be a valid CRC.
But I asked people to do just that and they reply it is still CRC error.
So there may be something else causing this.
It could very well be something as simple as the size of the struct being odd length and the CRC check needing even length.
We'll have to look into this to make sure what's happening here.

Hi. Today I wanted to upgrade my Wemos D1 mini pro trough and I had same issue. Even worst was because I was not able type using serial and webserver does not work. but console showing well and logs showed me settings crc failI. I tried back to earlier version and I flashed my device lot of time since I used a binary from first days of april.

I have same issue with sonoff TH10/TH16. For resolve i have flashed blank_1MB firmware and after last build.

And was the CRC error still present, even with a clean setup?

yes, but can boot.

I can confirm that I have been seeing this on serial during boot as well. All of my units are Wemos D1's V2.0.0, V2.2.0 and V3.0.0

Present on units newly flashed as well.

Just quickly checked adding a padding byte to the Settings struct to 20180419 (after SyslogFacility), then my Wemos D1 CRC errors disappeared on reset.
Still have problems connecting to web interface on 2 of 3 upgraded units.

OK, good to know that padding the settings struct has some effect.
I will add some function to automatically pad some to make the struct be a multiple of N bytes (probably N=4)

Seems settings related. Worked around that as follows:
For the non-responding units, I flashed (ESPeasy Flasher) 20180403 as distributed here, got CRC error on reset, OK CRC after save. Then OTA upgrade to 201804019 with the extra byte padding (btw built on Arduino 1.8.5, core 2.4.1), whereafter CRC is OK and nodes responsive again.

Hmm so it still is a possibility the core 2.4.1 is fixing stuff here?

There are too many things going on to pinpoint the causes.

Today I flashed
ESP_Easy_mega-20180420_normal_ESP8266_1024.bin
Minimal settings, DHCP
I got the web server responding, in an attempt to test CRC - FAIL, I issued a save command & cold booted
After this it would no longer join my wifi router.
Tries forever.
"ConnectFailures 0" - Always 0 ? Should this increment ?

INIT : Booting version: mega-20180420 (core 2_4_0)
75 : INIT : Cold Boot
76 : FS   : Mounting...
82 : FS   : Mount successful, used 73041 bytes of 113201
379 : CRC  : program checksum       ...OK
384 : CRC  : Settings CRC           ...FAIL
386 : CRC  : SecuritySettings CRC   ...OK
395 : INIT : Free RAM:20496
395 : INIT : SPI not enabled
410 : INFO : Plugins: 47 [Normal] (core 2_4_0)
411 : EVENT: System#Wake
428 : WIFI : Switch on WiFi
428 : WIFI : Set WiFi to STA
430 : WIFI : Connecting MAD_MOB attempt #0
443 : EVENT: System#Boot
451 : SW   : Switch state 0 Output value 0
454 : EVENT: FULL_Tray_2#Switch=0.00
1004 : WD   : Uptime 0 ConnectFailures 0 FreeMem 19648
10466 : WIFI : Connecting MAD_MOB attempt #1
26465 : WIFI : Connecting MAD_MOB attempt #2
....
2431014 : WD   : Uptime 41 ConnectFailures 0 FreeMem 19144
2436571 : WIFI : Connecting MAD_MOB attempt #155

EDIT while you zzzzz
I Cold Booted again somewhere, it joined for a while then

10981005 : WD   : Uptime 183 ConnectFailures 0 FreeMem 14488

Exception (28):
epc1=0x4024d872 epc2=0x00000000 epc3=0x40106d06 excvaddr=0x00000000 depc=0x00000000

ctx: cont
sp: 3fff46f0 end: 3fff4a00 offset: 01a0


>>>stack>>>
3fff4890:  3ffe8dc4 3fff3524 3fff48c0 3fff35a8

It continues the stack, want that ?

I will try to revert some things to go back to core 2.3.0.
We are experiencing a lot of issues lately which seem to be related to either bugs in core 2.4.0 or maybe even issues with full memory.

I can compile with platformIO same version as the releases which do not load & they then load OK, assuming is cause of older lib

Hmm, that's an interesting remark.
That would explain why I am not seeing a lot of the reported issues myself.

Feedback for
ESP_Easy_mega-20180422_normal_ESP8266_1024.bin
DHCP
ConnectFailures 0 ? Always 0 ?
No response from web-server

INIT : Booting version: mega-20180422 (ESP82xx Core 2_4_0)
76 : INIT : Cold Boot
77 : FS   : Mounting...
83 : FS   : Mount successful, used 73041 bytes of 113201
381 : CRC  : program checksum       ...OK
388 : CRC  : SecuritySettings CRC   ...OK
389 : CRC  : binary has changed since last save of Settings

Build changed!
Fix settings with uninitalized data or corrupted by switching between versions
891 : FILE : Saved config.dat
1192 : FILE : Saved security.dat
1193 : INIT : Free RAM:20448

1193 : INIT : SPI not enabled
1208 : INFO : Plugins: 47 [Normal] (ESP82xx Core 2_4_0)
1209 : EVENT: System#Wake
1229 : WIFI : Switch on WiFi
1229 : WIFI : Set WiFi to STA
1231 : WIFI : Connecting MAD_MOB attempt #0
1243 : EVENT: System#Boot
1254 : SW   : Switch state 0 Output value 0
1257 : EVENT: FULL_Tray_2#Switch=0.00
1267 : WD   : Uptime 0 ConnectFailures 0 FreeMem 19616
3376 : EVENT: WiFi#Disconnected
3381 : WIFI : Disconnected! Reason: '(201) No AP found' Connected for 2145 ms
3382 : WIFI : Connection Failed
3482 : WIFI : Set WiFi to AP
4376 : WIFI : AP Mode ssid will be ESP_Easy_0 with address 192.168.4.1
31267 : WD   : Uptime 1 ConnectFailures 0 FreeMem 18256
60398 : EVENT: Clock#Time=Thu,00:01
61267 : WD   : Uptime 1 ConnectFailures 0 FreeMem 18256
91267 : WD   : Uptime 2 ConnectFailures 0 FreeMem 18256

I see no "ESP_Easy_0" to connect to
Ok try wificonnect

571267 : WD   : Uptime 10 ConnectFailures 0 FreeMem 18256
>wificonnect
576184 : WIFI : Set WiFi to AP+STA
576308 : WIFI : AP Mode ssid will be ESP_Easy_0 with address 192.168.4.1
576309 : WIFI : Connecting MAD_MOB attempt #1


Ok
578456 : EVENT: WiFi#Disconnected
578461 : WIFI : Disconnected! Reason: '(201) No AP found' Connected for 2146 ms
578462 : WIFI : Connection Failed
578562 : WIFI : Set WiFi to AP
578565 : WIFI : AP Mode ssid will be ESP_Easy_0 with address 192.168.4.1
600456 : EVENT: Clock#Time=Thu,00:10

wifidisconnect
wificonnect

811267 : WD   : Uptime 14 ConnectFailures 0 FreeMem 18256
>wifidisconnect

Ok
840457 : EVENT: Clock#Time=Thu,00:14
841267 : WD   : Uptime 14 ConnectFailures 0 FreeMem 18256

>wificonnect
865246 : WIFI : Set WiFi to AP+STA
865249 : WIFI : AP Mode ssid will be ESP_Easy_0 with address 192.168.4.1
865249 : WIFI : Connecting MAD_MOB attempt #2

Ok
870299 : WIFI : Connected! AP: MAD_MOB (18:90:D8:AC:0F:D8) Ch: 7 Duration: 5047 ms
870300 : EVENT: WiFi#ChangedAccesspoint
871267 : WD   : Uptime 15 ConnectFailures 0 FreeMem 16664

LED slowly blinking, off, slowly full brightness, off....
No response from web-server
reboot

411 : EVENT: System#Wake
428 : WIFI : Switch on WiFi
429 : WIFI : Set WiFi to STA
431 : WIFI : Connecting MAD_MOB attempt #0
443 : EVENT: System#Boot

451 : SW   : Switch state 0 Output value 0
454 : EVENT: FULL_Tray_2#Switch=0.00
1004 : WD   : Uptime 0 ConnectFailures 0 FreeMem 19616
2574 : EVENT: WiFi#Disconnected
2578 : WIFI : Disconnected! Reason: '(201) No AP found' Connected for 2142 ms
2579 : WIFI : Connection Failed
2679 : WIFI : Set WiFi to AP
3573 : WIFI : AP Mode ssid will be ESP_Easy_0 with address 192.168.4.1

No access point "ESP_Easy_0"

121007 : WD   : Uptime 2 ConnectFailures 0 FreeMem 18256
>wifidisconnect

Ok
>wificonnect
144271 : WIFI : Set WiFi to AP+STA
144274 : WIFI : AP Mode ssid will be ESP_Easy_0 with address 192.168.4.1

144275 : WIFI : Connecting MAD_MOB attempt #1

Ok
146420 : EVENT: WiFi#Disconnected
146426 : WIFI : Disconnected! Reason: '(201) No AP found' Connected for 2145 ms
146426 : WIFI : Connection Failed
146527 : WIFI : Set WiFi to AP
146529 : WIFI : AP Mode ssid will be ESP_Easy_0 with address 192.168.4.1
151007 : WD   : Uptime 3 ConnectFailures 0 FreeMem 18256

I do some research. The problem results from Settings.ProgmemMd5. If i change the md5 calculation in the funtions SaveSettings and LoadSettings (misc.ino) as followed md5.add((uint8_t *)&Settings, sizeof(Settings)-32); (In the original code there are 16 not 32bytes), the crc then passed. If i have time, i do more research. Maybe i find the cause.

For debugging the md5 values i do some temporary changes in code as followed:

md5.calculate();
md5.getBytes(calculatedMd5);

// DEBUG
int count = sizeof(calculatedMd5) / sizeof(calculatedMd5[0]);
for (int i = 0; i < count; i++) {
Serial.printf("%02x ",calculatedMd5[i]);
}
Serial.println();
count = sizeof(Settings.md5) / sizeof(Settings.md5[0]);
for (int i = 0; i < count; i++) {
Serial.printf("%02x ",Settings.md5[i]);
}
Serial.println();
if (memcmp (calculatedMd5, Settings.md5,16)==0){
addLog(LOG_LEVEL_INFO, F("CRC : Settings CRC ...OK"));

Maybe it is useful for other developers ;-)

@Oxyandy It looks like your node does not get an IP, when it eventually gets connected.
It is quite strange it does not see the accesspoint you set.
But there is a line indicating it was using existing settings. Could you also try (may also be a different node if you like to keep the settings) with a clean setup? You can do serial commands, so you can also call Reset.

@Feuerreiter Have you seen the discussion at #1292 ?
The -supposedly- last 32 bytes of the settings are the MD5 of the firmware used and the MD5 of the settings. So if you leave out such a big part (19 bytes would also be enough I guess), there is no overlap in data used to compute the settings and the checksum itself.
The main problem is that there is a discrepancy between where we think the CRC is located and where it is actually located.
There may be a shift of up to 3 bytes, due to padding added by the compiler.
This means the CRC can be written inside the data area used to compute that very checksum. And by storing the CRC you change the data and thus the next time it is computed it will differ.

So in the last build, I left out the checksum from the settings (so it will not fail ;) ) until we think of a better way to deal with the checksum. We will run into the same issues when adding new members to the settings and still use CRC on that file.

@Oxyandy Could you restart your accesspoint?

I've seen it here a few times already that really fast reconnects can result in exposing bugs in the accesspoint firmware.
Maybe I should add some delay to the reconnect attempts.

@TD-er: whatā€˜s about embedding the config-structure into a ā€ž#pragma(pack)ā€œ?
And using the offsetof Macro (https://gcc.gnu.org/onlinedocs/gcc/Offsetof.html) to get the propper location / size of the volatile part?

Offsetof is quite new C++, not sure if Arduino IDE knows that

Itā€˜s a GCC builtin function so it also works with Arduino IDE. And you donā€˜t have to care about handmade errorprune offsets.

Hi @TD-er - been away from computer... Just saw your messages..
LED is same long slow - off, slowly brighter, off, I shutdown both my routers & cold booted them,
the ESP did not connect to either router.
Note it did not even try to connect to the second router & gave up after 1st attempt connecting to 1st

Issued reset.
The AP never appears either..

>reset
RESET: Resetting factory defaults...
RESET: Warm boot, reset count: 0
RESET: formatting...
RESET: formatting done...
30896530 : FILE : Saved config.dat
30896858 : FILE : Saved security.dat
RESET: Succesful, rebooting. (you might need to press the reset button if you've justed flashed the firmware)

 ets Jan  8 2013,rst cause:1, boot mode:(3,1)

load 0x4010f000, len 1384, room 16
tail 8

chksum 0x2d
csum 0x2d
v4ceabea9
~ld
��U74 :

INIT : Booting version: mega-20180422 (ESP82xx Core 2_4_0)
75 : INIT : Warm boot #2
76 : FS   : Mounting...
82 : FS   : Mount successful, used 75802 bytes of 113201
380 : CRC  : program checksum       ...OK
387 : CRC  : SecuritySettings CRC   ...OK
405 : INIT : Free RAM:20448
406 : INIT : I2C
406 : INIT : SPI not enabled
420 : INFO : Plugins: 47 [Normal] (ESP82xx Core 2_4_0)
420 : WIFI : Switch on WiFi
421 : WIFI : Set WiFi to STA
423 : WIFI : No valid wifi settings

424 : WIFI : Connection Failed
526 : WIFI : Set WiFi to AP
1416 : WIFI : AP Mode ssid will be ESP_Easy_0 with address 192.168.4.1
1423 : WD   : Uptime 0 ConnectFailures 0 FreeMem 18192
31424 : WD   : Uptime 1 ConnectFailures 0 FreeMem 18424

Serial setup & connect

>WifiSSID MAD_MOB

Ok
571426 : WD   : Uptime 10 ConnectFailures 0 FreeMem 18424
>WifiKey 12345676

Ok
>wificonnect
587844 : WIFI : Set WiFi to AP+STA
587847 : WIFI : AP Mode ssid will be ESP_Easy_0 with address 192.168.4.1
587848 : WIFI : Connecting MAD_MOB attempt #0

Ok
590913 : WIFI : Connected! AP: MAD_MOB (18:90:D8:AC:0F:D8) Ch: 7 Duration: 3064 ms
593676 : WIFI : DHCP IP: 192.168.0.104 (ESP-Easy-0) GW: 192.168.0.254 SN: 255.255.255.0   duration: 2763 ms
593680 : Webserver: start
594178 : FILE : Saved config.dat
594507 : FILE : Saved security.dat
594514 : Webserver: stop
594514 : WIFI : Connecting MAD_MOB attempt #0
601426 : WD   : Uptime 10 ConnectFailures 0 FreeMem 14536
604679 : WIFI : Disconnected! Reason: '(200) Beacon timeout' Connected for 10 s
604684 : WIFI : AP Mode Disabled for SSID: ESP_Easy_0
604685 : WIFI : Set WiFi to STA
604686 : WIFI : Connecting MAD_MOB attempt #1
607750 : WIFI : Connected! AP: MAD_MOB (18:90:D8:AC:0F:D8) Ch: 7 Duration: 3062 ms
608442 : WIFI : DHCP IP: 192.168.0.104 (ESP-Easy-0) GW: 192.168.0.254 SN: 255.255.255.0   duration: 692 ms
608443 : Webserver: start
616904 : WIFI : Disconnected! Reason: '(200) Beacon timeout' Connected for 9145 ms
616905 : Webserver: stop
616906 : WIFI : Connecting MAD_MOB attempt #0
618276 : WIFI : Connected! AP: MAD_MOB (18:90:D8:AC:0F:D8) Ch: 7 Duration: 1368 ms
619051 : WIFI : DHCP IP: 192.168.0.104 (ESP-Easy-0) GW: 192.168.0.254 SN: 255.255.255.0   duration: 775 ms
619052 : Webserver: start
627554 : WIFI : Disconnected! Reason: '(200) Beacon timeout' Connected for 9268 ms
627555 : Webserver: stop
627555 : WIFI : Connecting MAD_MOB attempt #0
627716 : WIFI : Connected! AP: MAD_MOB (18:90:D8:AC:0F:D8) Ch: 7 Duration: 158 ms
628551 : WIFI : DHCP IP: 192.168.0.104 (ESP-Easy-0) GW: 192.168.0.254 SN: 255.255.255.0   duration: 834 ms

Are you able to test your phone as a hotspot?

@Grovkillen
Ok, yes I have now tried that too, same errors.

123 : WIFI : Switch on WiFi
123 : WIFI : Set WiFi to STA
129 : WD   : Uptime 0 ConnectFailures 0 FreeMem 19048
130 : WIFI : Connecting DAD attempt #0
2273 : WIFI : Disconnected! Reason: '(201) No AP found' Connected for 2143 ms
2274 : WIFI : Connection Failed

Took current source too, compiled and flashed that
same, no luck

Ok, that's really a mystery at this point. :neutral_face:

In the mean time I have been reading on the ESP32 documentation about wifi, which is rather elaborate.
I think, I can explain this behavior.
Let's hope I get enough free time today to write a state machine to handle this.

Rolled Back to
ESP_Easy_mega-20180403_normal_ESP8266_1024.bin
connected immediately ;)

The settings got corrupted by this commit:
https://github.com/letscontrolit/ESPEasy/commit/1b9e1b92aa26ded75e23e0df7d2cd2cece19bba9
That was at april 4, which means all builds up to that commit should work.

Really a lot of bugs reports can be attributed to these corrupt settings.
And also a lot of attempts to fix something that wasn't broken as much as it seemed to be.

So there is actually 2 things I could do:

  • Split the event based wifi to a separate branch, and restore the wifi part to somewhere around 0319, when there was just async wifi.
  • Try to fix event based wifi today.

The issues why I introduced event based wifi was due to a misunderstanding of some reported issue that stated my changes did not work, while they worked just fine.
And the event based wifi became way too complex due to all the reported issues that were actually related to corrupted settings.

Option 3, step away from the computer, spend time with wife & kid,
try not to even think or worry about any of this...
Take a break..
If you are anything like me, your mind still works while you sleep,
you may wake up with a whole fresh approach

I'm totally at aw when it comes to your work around the event based wifi. I love how fast it is! I get that you want to revert back to safe ground but if it is possible to fix it within a week time frame I'm gonna say that's the path we should stay on. BUT if you feel that time is not enough then yes, we should go back and restore the brute force async approach 😁 until we get a stable v.2.1 release out into the wild.

Should I write something to the forum about this @TD-er ? Or should a wait a couple of days you think?

@Oxyandy I am outside, sitting in the shade, wife at work and Lilly (my daughter of 4) is catching salamanders with the neighbor kids.
So my programming mode is dormant at this moment and the brain is processing wifi information in the background.

Ah. Now that I'm reading this ticket, things start to make sense. Have been struggling a lot with upgrades not working after 20180403. Doing factory resets seems to help, but doesn't resolve all problems. I think it has something to do with wifi and maybe even user agents: with new releases (tried 20180421 and 20180423) I can connect to web server from Chrome on Windows(64) but whenever I try connecting to web server from Chrome on Android phone, the web service freezes and I can no longer connect from Chrome on Windows either. Outgoing requests to upload sensor data seem to continue, but I've seen these uploads halt at some point as well. (esp12f on wemos d1 mini)

(btw, not sure if this is relevant, but I'm using the test esp8266 4096 build, because I'm trying to get a set of mh-z19b sensors to work.)

No rush, I won't have time to work on this project for the next two weeks, but would be happy to do debugging if necessary after that.

INIT : Booting version: mega-20180424 (ESP82xx Core 2_4_0)
36460 : WIFI : Connecting MAD_IOT attempt #0
36873 : WIFI : Connected! AP: MAD_IOT (F4:F2:6D:25:84:C6) Ch: 11 Duration: 412 ms
37755 : WIFI : DHCP IP: 192.168.0.102 (ESP-Easy-0) GW: 192.168.0.254 SN: 255.255.255.0 duration: 881 ms
37756 : Webserver: start
46225 : WIFI : Disconnected! Reason: '(200) Beacon timeout' Connected for 9342 ms
46460 : Webserver: stop

There is something wrong in the reconnect logic at the moment.
Saw this one on my test sets also

@TD-er i do some research. In the function WifiCheck(), the wifiSetup variable prevents the calling of tryConnectWiFi();
Befor we made the fix with the static ip, the function processGotIP() set the wifiSetup variable to false.
'''if (wifiSetup) {

Ā Ā Ā Ā // Wifi setup was active, Apparently these settings work.

Ā Ā Ā Ā wifiSetup = false;

Ā Ā Ā Ā SaveSettings();

Ā Ā }
'''

Sry. I am at work and i am writing from my mobil phone. ;-)
If i have more time i try to find a solution for this problem

I've seen the error last night, so I will try to fix it this evening.... if I got some time.
I is quite a busy period for me, the last few months. We just got news about what's going to happen with the houses in our street, so I hope I can get my head into programming mode, since a lot of stress is now in the past.... I hope.

@TD-er Thanks a lot for your effort here but you know - your personal life is a top priority. Take care... Hopefully everything'll be OK...

Well I guess the big hurdles are now past us.
In short; I live in Groningen, in the Netherlands. There are earthquakes due to gas mining.
So a lot (!!!!) of houses have to be re-enforced to withstand those quakes and our entire street will be demolished and rebuilt. About 20k houses will have to be re-enforced.
This we know already for about 3 years and now it finally will happen, the government is starting to back off and is trying to enter new changes to the law so they will no longer be held accountable for the damages. Today we heard that the 1467 houses that already were discussing with the contractors about the houses, will continue and the rest will have to wait longer. So that's the next hurdle, but for now we have a "yes" about continuation of the process. (for the 2nd time...)

So that's the short story about what's keeping me busy in my head apart from my family, my work and nerd stuff.

@TD-er I must say thank you too. Under this circumstances its really comprehensible that you don't have got the head free for programming. I wish you and your family a lot of luck. I am agree with ghtester. Your personal life has prio.

Well, I really need nerd-stuff like this to keep my mind together, so as long as this project goes well, the rest will also follow :)

At least now, I can relax a bit more, since there is now media coverage and a lot more people actively involved in getting this process going.
So now there is more time for preparing the best possible house automation system for our new house :)

Well, I understand it's all about the big money... I have experienced a flood many years ago so I can imagine what means when your home is in danger and you don't know what will happen... I really hope your government will compensate all of you in the end as you deserve and you won't wait for your new house too long.

It will take about 1.5 year from now, at least (probably 2) for our houses.
But our government has just tried to get some changes of the law pass silently to make them no longer responsible for the damages. That was one of the things I was also working on, to get that one noticed and write about it what it would mean for us.

So don't expect too much from them.

@Feuerreiter CRC : Settings CRC ...FAIL solved
So that means we roll back to 0403 ? Make a 0405 with the fix & there after ?
Noting that with my hardware 0403 has no wifi errors, post builds regardless of core used - have issue ..

I only found the solution for the problem hansrune discript. "Still have problems connecting to web interface on 2 of 3 upgraded units." TD-er write about this problem too. "There is something wrong in the reconnect logic at the moment." I do my work. I don't think we should step back because security, speed reasons.

Just to clarify 0403 is only the 3rd of April 2018
There was no release on the 4th, the 5th introduced the "CRC : Settings CRC ...FAIL"
for sure some improvements were made in that time, but some problems were introduced..
Rewind to the 3rd merge all the important changes since then,
take what TD-er has learnt in that time (good & bad) & try again.

So, does rolling back to 0403 allow one to maintain config and resolve the CRC errors and WIfi connect issues? Is there then a new version to roll forward to that will allow all to work?

It should be able to go from 0403 to 0430.
I tried last week from various versions to the last version at that time and it worked without issues.
That was from versions dating back to February till begin of April.
It was done as a test for the patched settings.
It should work, if you go back to 0403 and then save the settings, then upgrade to 0430.
You want to save the settings using a 20100 build and then use it in 20102 build. (build showing in sysinfo and also on the main page if you're using UDP sync between the ESPeasy nodes)

0403, not tested by me much overall

  • other than Wifi stability, tested many times for long periods, it's great (even using 2.4.1 core)

Note: many firmwares in between have been useless, compiling with 2.3.0 core some load OK
but still troubles
0429 tested heaps, very, very happy with wifi connectivity
0430 wifi issues making it useless
Yes, I have gone up/down, without settings breaking, but they have been minimal settings mainly for testing Wifi- and these finding have been with 'my hardware' - seems others have differing results.
I am pedantic with my testings, I don't blurt out the first thing I see - last thing I want to do is steer developers in the wrong direction.

I will close this, open if its still a valid issue.

Was this page helpful?
0 / 5 - 0 ratings