[BUG] No readable EEPROM address for option 62 during boot log

[fredlcore]

[BUG] No readable EEPROM address for option 62 during boot log

[dukess]

Try to disable power saving. When i switched off it i got clean output:

Address EEPROM option 58: 1497
Address EEPROM option 59: 1498
Address EEPROM option 60: 1499
Address EEPROM option 61: 1501
Address EEPROM option 62: 1503
Address EEPROM option 63: 1504
Address EEPROM option 64: 1505
Address EEPROM option 65: 1506
Address EEPROM option 66: 1507
Logging output to Telnet
Size of cmdtbl: 126644

[fredlcore]

Sorry, my bad, this is just a problem of the serial port output when using ESP32 power saving. The switch from 240 to 80 MHz results in a short confusion in the serial port transmission speed and therefore characters are garbled up.

[dukess]

If the problem with the output of garbage content when switching the frequency occurs only in the serial port, and the output to the http connection or file is not affected, then I think it will be enough to mention this feature in the documentation. From a perfectionist's point of view, it's worth thinking about stopping the serial port before switching frequencies, but is there any need for this?

[fredlcore]

Disabling serial output prior to switching CPU frequency solves the issue, so no more confusion now :)...

[DE-cr]

Just fyi: espressif/arduino-esp32#6032 sounds related and may contain some useful information.

[dukess]

It should be CF_CONFIG_LEVEL. I looking for suspicious things but found nothing for first sight. But i fix something|: 4d6eeec

[fredlcore]

Does this show in your startup messages, too? Or is it just me?

[dukess]

Yep i got same problem at startup

[dukess]

But it looks little bit different:

Address EEPROM option 55: 1463
Address EEPROM option 56: 1464
Address EEPROM option 57: 1496
Address EEPROM option 58: 1497
Address EEPROM option 59: 1498
Address EEPROM option 60: 1499
Address EEPROM option 61: 1501
Address EEPROM option 62: 1503
Addres⸮�*�AI=5⸮option 63: 1504
Address EEPROM option 64: 1505
Address EEPROM option 65: 1506
Address EEPROM option 66: 1507

Can it be issue with buffer size/cleanup?

[dukess]

BTW: line
printFmtToWebClient("\r\n%s\r\n",cleanupDatalog(nDays));
can cause unpredicable behavior because cleanupDatalog() and printFmtToWebClient() functions use same buffer: bigBuff

[fredlcore]

Hm, changing OUTBUF_LEN which is used for DebugBuffer from 450 to 550 leaves the error on the same position. As each line is ca. 30 Bytes, 450 Bytes would have been "hit" after 15 lines already. It rather seems to me as if some other part of the code overwrites DebugBuffer during this process because after these strange characters, the text continues unchanged. If it was a buffer problem of DebugBuffer, there should be unreadable text after the end of the buffer, shouldn't it?

[fredlcore]

I tried to add a direct Serial.println of getEEPROMaddress to the code part where it outputs the addresses, so it looks like this:

  for (uint8_t i = 0; i < CF_LAST_OPTION; i++) {
    Serial.println(getEEPROMaddress(i));
    printFmtToDebug(PSTR("Address EEPROM option %d: %d\r\n"), i, getEEPROMaddress(i));
  }

Now it looks like this:

Address EEPROM option 59: 2077                                                  
2078                                                                            
Address EEPROM option 60: 2078                                                  
2080                                                                            
Address EEPROM option 61: 2080                                                  
2082                                                                            
Address EEPROM option 62: 2082                                                  
2083                                                                            
Address EEPROM option 63: 2083                                                  
2p??j                                                                           
     Address EEPROM option 64: 2084  

That's really strange, because now the DebugBuffer output seems to be fine, but the direct output to serial of getEEPROMaddress(i) results in strange characters for EEPROM option 64. This is really strange to me because getEEPROMaddress(i) really just returns the value of options[id].eeprom_address. And how can this return some strange characters in one line and then the correct value in the next?

[fredlcore]

Even more strange: I changed the above code snippet to output the length of DebugBuffer as well as the value in HEX and then both the hex value as well as the decimal value are correct for all addresses and the length of DebugBuffer is always correctly 32 bytes, but somehow strange characters still get added.

81E                                                                             
32                                                                              
Address EEPROM option 60: 2078                                                  
820                                                                             
32                                                                              
Address EEPROM option 61: 2080                                                  
822                                                                             
32                                                                              
Address f`PROM option 62: 2082                                                  
823                                                                             
32                                                                              
Address EEPROM option 63: 2083                                                  
824                                                                             
32                                                                              
Address EEPROM option 64: 2084                                                  

[fredlcore]

Great minds think alike at the same time ;)...

[fredlcore]

@DE-cr, can you please have a look at this: #580 (comment)
Thanks!

[dukess]

@DE-cr you can review 3c97200

[fredlcore]

Oh, I see @dukess is already fixing it:
3c97200

[dukess]

@1coderookie we should mentioned in documentation about strange symbols in serial output when power saving mode activated.

[DE-cr]

@1coderookie we should mentioned in documentation about strange symbols in serial output when power saving mode activated.

...which happens repeatedly in case of boolean esp32_save_energy = true; in BSB_LAN_config.h, unless there's also #define WIFI configured.

[fredlcore]

Why would it happen repeatedly? The only times it runs is during startup and when downloading the log data (e.g. for displaying the graph), so the occasions are clearly defined.

[DE-cr]

Exactly: whenever (i.e. repeatedly) log data gets sent to the client.

[fredlcore]

Sorry for the (now deleted) rant.
But do you really think that it's the same if we write:
"The log output will repeatedly display a 'Ping' message containing the uptime in microseconds"
and
"The log output will repeatedly display garbled characters"?

I would find it much more helpful to idenfity the conditions under which this takes place. Your above statement is wrong because while it does occur repeatedly every time there is a reboot and power saving is enabled, it is however not tied to #define WIFI. It will happen also when using Ethernet at that point.
However, the only other time I can see this happening is only if the following conditions are met:

• Network connection is Ethernet (i.e. WIFI definement is commented out)
• Logging is activated
• Log data is downloaded

So my question above was not to start a discussion about the meaning of "repeatedly" where we seem to have different understandings about its commonly used form, but I seriously wanted to know if you have spotted other parts in the code where this will (repetedly or not) affect serial output. Since I know you are a good programmer, I'm honestly interested in your input in these matters, but these repeated ;) semantic discussions are simply not helping at all.

[DE-cr]

I'm sorry for having caused confusion here (again - and not even having clarified it with my "Exactly" above).

The only places I'm aware of where setCpuFrequencyMhz() gets called is at startup and at the beginning and at the end of handling urls that start with /D, and even there only under the conditions given: esp32_save_energy == true, and for the /D commands additionally required defined(ESP32) && !defined(WIFI).

As for your question: The answer is "no", but the question confuses me. :)

[fredlcore]

👍

[fredlcore]

Haven't thought about stopping and starting the serial port, will try this out. Otherwise: Yes, it only affects serial output, and only when CPU speed is switched, nothing else.