What is this garbled mess from serial monitor?

Projects General Guidance
1

Sometimes my board spits out a line of garbled text to the serial monitor. I don't know what this line is supposed to be... I don't think it's from my code, it could possibly be from a library or a core debugging line (which is curently set to "info"). When I pasted it here, it was all the same character, but in serial monitor it's a mixture of non alphabetical characters.

My board is an ESP32-WROOM-32D
I'm currently using a baud rate of 921600, but it's happened with 115200 and 9600 as well. 921600 is the baud rate that gets set when uploading the code, so that's why I chose that.

Any help as to what causes this sort of thing?

Thanks

21:04:33.493 -> TeamID: 21 Scored a goal
21:04:33.493 -> Old Score: 0 New Score: 7
21:04:36.011 -> �����������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������
21:04:36.406 -> === Starting Goal Light System ===
21:04:36.406 -> ESP32 Chip ID: 1061182421

2

I would be surprised if it wasn't. When the ESP starts running your code, the bootloader sends diagnostic messages at a default baud rate (typically 74880). The IDE switches the baud rate to whatever you set in Serial.begin(), but only after those early messages have already been sent.

To avoid confusion or missed output, I simply add a delay(3000); at the very top of setup(). This gives the serial monitor time to connect at the correct baud rate before your code starts printing. That usually solves the issue for me. The delay also gives you time to fix a serial flood.

If you check the forums, you’ll find other suggestions too.

Also, keep in mind: for serial output to display correctly, the Serial Monitor baud rate must match what you set with Serial.begin(XXXX);. If they don't match, you'll see garbage characters or nothing at all.

3

Perhaps, if you follow the forum rules and post code and wiring.

4

Helpful. Thank you.

5

This is a general guidance forum. I am looking for general guidance on why the serial monitor would display garbled characters if the baud rate matches what I've specified in my serial.begin... I'm not asking anyone to specifically troubleshoot my 660 lines of code.

6

Problem could be in the code, the peripheral, the wiring or the baud rate.

Have fun!

7

Interesting. I hadn't considered that. Thank you for your contribution to the general guidance forum.

8

The usual reasons for a "garbled mess" in the Serial monitor is that something has output data at a bit rate different than the setting of the monitor code.

IIRC, the ESP code does some output from its bootloader, and more output at system initialization time, and those are independent from whatever you've set in setup() (which happens quite late in the board initialization.) (Also, the baud rates used tend to be "weird.")

921600 is the baud rate that gets set when uploading the code.

the bootloader sends diagnostic messages at a default baud rate (typically 74880).

Two weird bit rates... You can try using assorted other bitrates in the Serial Monitor, and see if your garbled text moves. (But with such weird rates, it might be problematic...)

You can also see garbled output if something mistakenly sends binary data when it was expecting to send text, due to an uninitialized buffer or something...

9

What does that show? You only told us what you see, not what you did.

It looks like you board was working (first text lines), did reboot for whatever reason (maybe you did an upload?) and the last text output shows the start of your sketch?

I'm not an user of ESP32 based boards but I've seen unreadable data before on the forum for ESP32 based boards; as far as I know it is "left over data" from the bootloader or upload process that you see.

10

Do you have an option to change (increase) flash memory speed?

12

Your assessment of the provided copy/paste was correct. The board was working, crashed and restarted. So I think this exact occurrence was probably caused by the difference between the bootloaders default baud rate and my serial.begin() as some people have been pointing out.

However, that is just one scenario in which this sort of thing occurs. Upon booting up, once the loop() is running and my code is executing, it will happen with Serial.println and Serial.printf statements as well. In my loop() I'm making an API call and the lines in bold below are from a Serial.println of a string literal. Any of the Serial.print statements below have shown this behavior from time to time though. So have other prints scattered throughout my code. It can happen with String variables or character arrays. If/when a variable is involved in the Serial.print, it doesn't affect functionality at all, it's just displayed incorrectly in the serial monitor. The next iteration of the loop, this same statement will usually display correctly. It's consistently sporadic.

15:19:26.971 -> [HTTPS] begin...
15:19:28.373 -> [HTTPS] GET... code: 200
15:19:28.507 -> R���:�m�
15:19:28.507 -> %V�͕5
15:19:28.507 -> Response length: 16948 characters

 if (client) {
    client->setCACert(rootCACertificate);
    client->setTimeout(5);
    {

      HTTPClient https;
      Serial.print("[HTTPS] begin...\n");
  
      if (!https.begin(*client, "https://api-web.nhle.com/v1/scoreboard/" + String(teamURL) + "/now")) {
        Serial.println("[HTTPS] Unable to begin HTTPS connection");
        delete client;
        return;
      }

      int httpCode = https.GET();
      Serial.printf("[HTTPS] GET... code: %d\n", httpCode);

      if (httpCode > 0) {
        if (httpCode == HTTP_CODE_OK || httpCode == HTTP_CODE_MOVED_PERMANENTLY) {
          // Add a small delay to ensure all data is received
          delay(100);
          
          // Get the complete response as a string
          apiResponse = https.getString();
          **Serial.println("Received API response");**
          Serial.printf("Response length: %d characters\n", apiResponse.length());
          Serial.println(apiResponse);

        } else {
          Serial.printf("[HTTPS] GET... failed, error: %s\n", https.errorToString(httpCode).c_str());
        }
      } else {
        Serial.printf("[HTTPS] GET... failed, error: %s\n", https.errorToString(httpCode).c_str());
      }
      https.end();
    } // end client scoping block
     
     delete client;
  }
  else {
    Serial.println("Unable to create client");
  }
13

I'm using the Arduino IDE... this is the Tools>Upload Speed setting, right? Is so, then no, 921600 is the highest speed available.

14

What are the results when you try helloworld?

You should post your full sketch.

Garbled text in the monitor is due to signal quality... that could be mismatched baud (reading characters at the wrong time) or bad ground (zero and one not falling in the voltage level needed to make a 0 or 1). Change your data cable. Change your ESP.

Are you using an FTDI comm board?

15

The web site linked below has an anti-bot widget running... which looks unfriendly to the viewer... so I am posting the link in a code block... you will need to copy/paste

https://esp32.com/viewtopic.php?t=3884
16

No, I'm not. I'm using a board that was sold commercially as a goal light for NHL games but didn't work very well so I decided to take a stab at reprogramming it myself. There's a micro usb-b connection on it that I'm using to connect to my windows pc.

I've learned that the boards UART communication default baud rate is actually 115200. So based off that and the other info in this thread, I've switched to Serial.begin(115200), added a small delay to setup() and changed USB cables. The number of occurrences of the garbled, missing, or otherwise messed up text is definitely improved, though it still happens.

I obv don't know a whole lot about arduinos yet but I was expecting Serial.print to work as reliably as a a python print() or a C# Console.WriteLine. I think what I'm learning is that that's just not the paradigm in play here given the connection from one cpu to another via the serial port.

Thanks for your input.