possible bug, rebooting after reflash

[hieromon]

possible bug, rebooting after reflash

[Hieromon]

Hi,
You too?!, I've been working on a similar issue in recent weeks. I am not every time but if I missed erase_flash sometimes the module behaves wrong. In my case, it happens at the moment of loading the program from flash. That's why I can not diagnose the problem yet.

some variables for wifi network are stored in program memory?

AutoConnect saves the credentials to EEPROM only. AutoConnect writes the SSID and password to the EEPROM when the connection is successful. If the partition of EEPROM is misaligned, it may crash.
https://arduino-esp8266.readthedocs.io/en/latest/filesystem.html#flash-layout
Is the flash layout changed with esp8266 core 2.5.0 Upstream & Update SDK?, I will check.

Can you take logs of AutoConnect, Page Builder and esp8266 core? I can start P.D. with it as a clue.
I always let you do the analysis ...Thank you! :)

[ageurtse]

isn't it possible to write the data to a config file in spiffs, so it wouldn't over write, or if you which to use eeprom, write it at the end of eeprom.

I try to reproduce the problem and turn on debugging.

[ageurtse]

i'm looking to store my custom variables in eeprom, but you use eeprom to for saving wifi creditionals.
could the problem come from this.

i'm trying to find where the eeprom is stored in the program, is this at the end of the programm, or is it at the end of all memory ?

if it is at the end of the program, then that is problaly your problem, if a program has a different size, the data is overwritten and there by corrupt.

if not, can i also make use of the eeprom ?

[ageurtse]

or perhaps, you don't alocate enough memory for eeprom ?

[Hieromon]

@ageurtse I apologize for my poor English and hope that my reply gets through to you.

i'm trying to find where the eeprom is stored in the program, is this at the end of the programm, or is it at the end of all memory ?

The EEPROM area is located between File System and SDK reserved area and depends on the partition table defined in the Arduino core. At first, please refer to this document to share my views with you.

if it is at the end of the program, then that is problaly your problem, if a program has a different size, the data is overwritten and there by corrupt.

The EEPROM start address is defined by the SDK and is located by the EEPROM library of the arduino core.

_SPIFFS_end & SPI_FLASH_SEC_SIZE

https://github.com/esp8266/Arduino/blob/82da5c76b97e3c8dfb6bb97fc74fd74c6733040f/libraries/EEPROM/EEPROM.cpp#L44

Is your doubt is probably this?
Move the saving area of EEPROM for the credentials

As the esp8266 document shows, the SDK uses the backward of the EEPROM area. If AutoConnect destroys the SDK reserved area to save the credentials, your expected scenario will be possible. The data structure of the credential storage is variable length, and it is a maximum of 104 bytes per one entry. In addition to this, it has the number of saved entries at the beginning of the area and the area identifier. Please refer to the EEPROM data structure for the credential saving in the chapter the FAQ for details.

If this entry structure is destroyed by confliction with the user sketch using, AutoConnect might save the credentials to the misplaced location which may also be the reserved area of the SDK. So, to avoid this, I applied the following two measures.

1. Move the credential saving area.

   With the boundaryOffset option of AutoConnectConfig, the sketch can move the credentials saving area. The boundaryOffset specifies the gap from the head of EEPROM. As a result, its size becomes a freely usable area with sketches.

                                         boundaryOffset (Default = 0x00)
                                          v
|--------------|-------|---------------|--|--|--|--|--|
^              ^       ^               ^     ^
Sketch    OTA update   File system   EEPROM  WiFi config (SDK)

2. Check the identifier before save.

   AutoConnect checks the identifier of the head of credential are in the EEPROM before saving. If no identifier is found, AutoConnect will not save the credentials.

But still there is a possibility that AutoConnect will destroy that area. AutoConnect will save a credential each time a connection establishment for the AP and reuses the EEPROM area by overwriting the same SSID of a BSSID. Even if the SSID is the same and the BSSID is different, it will be appended to the area. There is a possibility of destroying the SDK reserved area at the backward by the credential appending. It will occur at the number of saved entries greater than 40.

You can use the ESPShaker to dump the EEPROM. If you can the EEPROM dump with eeprom command of the ESPShaker, I can proceed with the problem analysis. Can you try? or Do you have something to dump tool for EEPROM?

[Hieromon]

Also, the cause of my side was from the breadboard. It caused current leakage.
I wrestled with the oscilloscope until reached the cause, but in the end, I replaced the breadboard into a new one, so the problem has not happened so far.

[ageurtse]

working on a new sketch for my ac dimmer project, stil no problem with reflashing.
So i think it is solved, for me this could be closed.

[Hieromon]

I'm glad the problem was solved.