Stability issue: parity error due to sporadic glitch causes fw update to fail

[maehw]

Describe the bug
A parity error due to sporadic glitch causes the firmware update to fail - even though communication has retry attempts included.

To Reproduce
Steps to reproduce the behavior:

1. Go to https://test.webpbrick.com/firmware/index.html
2. Open web developer JavaScript console for details
3. Connect via serial and start fw download
4. See the fw download fail

Expected behavior
Sporadic glitches only cause retry attempts of communication but no complete failure.

Screenshots

Operating system & webbrowser:

• OS: Microsoft Windows 10 Pro
• Browser: Chrome Version 143.0.7499.148 (Offizieller Build) (64-Bit)
• Version: current test, commit hash see screenshot

RCX hardware & firmware:

• RCX hardware version: 1.0 (serial 628154)
• RCX firmware version: n/a
• IR tower: LEGO Serial IR Tower + USB/serial adapter

Additional context
I'll add the logic analyzer trace here.

[RXM] 0x00 0xFF for the response of downloading block #170 is unexpected. This must be caused by the sporadic glitch shown in the logic analyzer trace.

The re-transmission of the block... or rather the command 0x10 before the retry unveils a "parity error", i.e. the UART RX mechanism claims that the received block is invalid regarding the parity bit. All 10 further attempts to download the same firmware block fail with more "paritiy errors". The glitch probably introduces the reception of an invalid UART frame and keeps the UART receiver in an invalid state where it cannot recover from. Let's re-connect the serial device (in this case the USB/serial converter) and hope that this will recover to a sane state where it can continue TX/RX... and retry downloading the block.

[maehw]

Notes:

• UART signals here are inverted here (i.e. IDLE LOW; LOW=VCC; HIGH=GND).
• Full trace:
  Session 0.sal.zip (use Saleae Logic to view)

The details, in timely order:

At marker T1: ContinueFirmwareDownLoad/ContinueDL (0x45) command with parameter byte 0xA9 = 169decimal => block #169
Got a response from the RCX, WebPBrick reports success.

At marker T0 (later than T1, sorry for potential confusion): ContinueFirmwareDownLoad/ContinueDL (0x45) command with parameter byte 0xA9 = 169decimal => block #169

A short (around 94 microseconds long) sporadic glitch appears - this may lead to the detection of a new UART frame (start bit)... and

At marker T2: ContinueFirmwareDownLoad/ContinueDL (0x4D) command with parameter byte 0xAA= 170decimal => block #170
Attempt to download the next firmware block. Got a response from the RCX but WebPBrick reports a download error! It also reports having received 0x00 0xFF - which is likely caused by the glitch.

At marker T3: PBAliveOrNot/ContinueDL (0x10)
Attempt to check if RCX is alive. The RCX actually responds, but WebPBrick does not receive anything and reports a parity error.

From here on, communication has also died from the RCX side - it doesn't respond to future requests anymore.

At marker T4: ContinueFirmwareDownLoad/ContinueDL (0x4D) command with parameter byte 0xAA= 170decimal => block #170 (re-transmission)