Is the Mesh devices UART implementation buggy?

I also have big problems with the reliability of the UART implementation on the mesh devices. I read about these two bugs:

  • Serial.available() can also return negative values if no data is available, should return 0
  • Serial.read() can return other negative values than -1 if no data is available

If this would be everything, working around is easy. But I think there are more and stranger problems. After searching and testing a lot, I made this small program running on an Argon (0.9.0) with Rx and Tx pins connected:

void setup() {
    Serial1.begin(115200);
    Log.info("ok");
    pinMode(D7, OUTPUT);
}

void loop() {
    Serial1.print("abc");
    delay(10);
    digitalWrite(D7, HIGH);
    
    int ava = 0;
    int rd = 0;
    
    ava = Serial1.available();
    rd = Serial1.read();
    if(ava != 3) Log.warn("1a %i", ava);
    if(rd != 'a') Log.warn("1b %i", rd);
    
    ava = Serial1.available();
    rd = Serial1.read();
    if(ava != 2) Log.warn("2a %i", ava);
    if(rd != 'b') Log.warn("2b %i", rd);
    
    ava = Serial1.available();
    rd = Serial1.read();
    if(ava != 1) Log.warn("3a %i", ava);
    if(rd != 'c') Log.warn("3b %i", rd);
    
    ava = Serial1.available();
    rd = Serial1.read();
    if(ava > 0) Log.warn("4a %i", ava);
    if(rd >= 0) Log.warn("4b %i", rd);
    digitalWrite(D7, LOW);
}

If everything is fine, there should be no Log outputs. But there are Log outputs:

0000009913 [app] WARN: 1a 2
0000009914 [app] WARN: 2a 1
0000009968 [app] WARN: 1a 2
0000009968 [app] WARN: 2a 1
0000010073 [app] WARN: 1a 1
0000010127 [app] WARN: 1a 1
0000010226 [app] WARN: 1a 2
0000010226 [app] WARN: 2a 1
0000010275 [app] WARN: 1a 2
0000010276 [app] WARN: 2a 1

This goes on like that forever.
Please have a look at the timestamps in the Logs. The delay(10) causes the loop to be executed about 100 times a second. The warnings appear much rarer. Warning 2a is always after warning 1a, but 1a is not always followed by 2a. 3a never appears.
Changing the loop speed by adjusting the delay changes the error frequency accordingly.

What is going on here? I can not explain this with the known bugs of read() and available(). These problems are causing a lot of strange effects in my production firmware.

2 Likes