Bug-fix release EspSoftwareSerial 6.5.3

[dok-net]

Pending approval by 3rd party bug reporter

[dok-net]

@earlephilhower Done and ready for merge now. Thanks!
EDIT: have to go back to WIP. I'll keep you posted.

[dok-net]

@earlephilhower This 6.5.1 release fixes #6920, which on it's own is worth merging.
Unfortunately, I am giving up for the moment on a sporadic crash/reset that I see under test - HW sends continuously to EspSoftwareSerial/examples/repeater sketch - but I am unable to locate a cause in due time. I am open for suggestions - it happens on different boards:

Effective data rate: 8140bps, 0cps seq. errors (0.00%) (0 parity errors)
Effective data rate: 8150bps, 0cps seq. errors (0.00%) (0 parity errors)
Effective data rate: 8160bps, 0cps seq. errors (0.00%) (0 parity errors)
��!��L�<1�1DRepeater example for EspSoftwareSerial
Effective data rate: 8150bps, 0cps seq. errors (0.00%) (0 parity errors)
Effective data rate: 8160bps, 0cps seq. errors (0.00%) (0 parity errors)
Effective data rate: 8160bps, 0cps seq. errors (0.00%) (0 parity errors)

Not much to go by on USB logging.

I wonder if IRAM is exhausted :-( ?

Executable segment sizes
IROM   *: 237712          - code in flash         (default or ICACHE_FLASH_ATTR)
IRAM   *: 28860   \ 32768 - code in IRAM          (ICACHE_RAM_ATTR, ISRs...)
DATA   *: 1252  )         - initialized variables (global, static) in RAM\HEAP
RODATA *: 848   ) \ 81920 - constants             (global, static) in RAM\HEAP
Program size: 268,672 bytes (used 26% of a 1,044,464 byte maximum) (29.49 secs)
BSS    *: 25520 )         - zeroed variables      (global, static) in RAM\HEAP
Minimum Memory Usage: 27620 bytes (34% of a 81920 byte maximum)

On ESP32, running same EspSoftwareSerial release, have yet to see this once the first time.

[earlephilhower]

OK, @dok-net, will wait for you to give all clear.

IRAM is statically allocated. It either has enough space, and you get successful link, or it doesn't and you don't get an .ELF out, so it's not that.

Are you getting anything on the HW serial port for the resets? WDT is one place the -32 and the 8266 are very different.

Don't sweat the Win build failures. Looks like the early access Win VMs started pooping the bed. I'll look at it tonight, and if I can't figure out then I'll pull the Win build for now. Just worry about your own SWSerial stuff.

[dok-net]

First findings running repeater.ino for a few hours overnight: Reprogrammed with erasing complete flash memory, no crashing. This means the WiFi isn't set up at all.

Now adding

    WiFi.mode(WIFI_STA);
    WiFi.begin("...", "...");

    // Wait for connection
    while (WiFi.status() != WL_CONNECTED) {
        delay(500);
        logger.print(".");
    }
    logger.println("");
    logger.print("IP address: ");
    logger.println(WiFi.localIP());

to setup() (and the requisite includes to the top of the file). This is facilitated by release 6.5.2, no breaking changes or even any change outside the examples at all.

But now, running with WiFi setup again, BOOM after a few seconds or minutes:

Effective data rate: 8180bps, 0cps seq. errors (0.00%) (0 parity errors)
Effective data rate: 8160bps, 0cps seq. errors (0.00%) (0 parity errors)
��!��L�<1�1dRepeater example for EspSoftwareSerial
Effective data rate: 8100bps, 0cps seq. errors (0.00%) (0 parity errors)
Effective data rate: 8180bps, 0cps seq. errors (0.00%) (0 parity errors)

@earlephilhower This is on USB serial, same as I said before - isn't that the HW serial port that you are referring to, I have no other? This means there is no diagnostics at all.

Anyway, in my mind this means there is no acute reason to believe this is caused by EspSoftwareSerial, specifically there is no regression, and 6.5.2 should be merged now to close the linked issue.

Further testing:
WiFi.forceSleepBegin(); in setup(), no crash during 2-3 hours.
But when attached to AP, restarts after a few minutes uptime.

[dirkmueller]

@earlephilhower could you please review and merge? I am a bit impatient with this, sorry 🙂

[dok-net]

@dirkmueller In case you're a user of the fairly new parity/9bit feature, while searching for a cause of the resets I found and fixed a loss-of-sync bug - the parity reported drifted permanently from the actual data if there was an overflow. This occurred during delays >= 400ms at 19200bps, for instance :-)

[dok-net]

I didn't expect any of the changes to fix this, because I do not think it's anything in EspSoftwareSerial:

Effective data rate: 8170bps, 0cps seq. errors (0.00%) (0 parity errors) Uptime: 273098ms
��!��L�<1�1GRepeater example for EspSoftwareSerial
..
IP address: 192......
Effective data rate: 8270bps, 5cps seq. errors (0.67%) (20 parity errors) Uptime: 3195ms
Effective data rate: 8190bps, 0cps seq. errors (0.00%) (0 parity errors) Uptime: 6125ms

(19200bps)
and

Effective data rate: 3890bps, 0cps seq. errors (0.00%) (0 parity errors) Uptime: 69555ms
��!��L�<1�1GRepeater example for EspSoftwareSerial
..
IP address: 192......
Effective data rate: 3910bps, 0cps seq. errors (0.00%) (0 parity errors) Uptime: 3363ms
Effective data rate: 3890bps, 0cps seq. errors (0.00%) (0 parity errors) Uptime: 6444ms

(9600bps)
and

Effective data rate: 3880bps, 0cps seq. errors (0.00%) (0 parity errors) Uptime: 61973ms
Effective data rate: 3880bps, 0cps seq. errors (0.00%) (0 parity errors) Uptime: 65060ms
��!��L�<1�1GRepeater example for EspSoftwareSerial
..
IP address: 192.168.178.27
Effective data rate: 4070bps, 28cps seq. errors (7.08%) (0 parity errors) Uptime: 3239ms
Effective data rate: 3990bps, 23cps seq. errors (5.92%) (0 parity errors) Uptime: 6241ms
Effective data rate: 3890bps, 0cps seq. errors (0.00%) (0 parity errors) Uptime: 9324ms
��!��L�<1�1GRepeater example for EspSoftwareSerial
..
IP address: 192.168.178.27
Effective data rate: 3910bps, 0cps seq. errors (0.00%) (0 parity errors) Uptime: 3359ms
Effective data rate: 3890bps, 0cps seq. errors (0.00%) (0 parity errors) Uptime: 6441ms

(9600bps)
and so forth...
Or else, still going strong:

Effective data rate: 3850bps, 0cps seq. errors (0.00%) Uptime: 2760391ms
Effective data rate: 3850bps, 0cps seq. errors (0.00%) Uptime: 2763500ms

Let's watch this, but not in this PR. Please really do merge.
Update: >5h continuously running.