Garbage on HardwareSerial ESP32S2 at 3.0.4

[olagt]

Board

ESP32S2

Device Description

S2 Mini

Hardware Configuration

PIN RX 18 , TX 16

Version

v3.0.4

IDE Name

Arduino IDE

Operating System

WIN 10

Flash frequency

80

PSRAM enabled

yes

Upload speed

940000

Description

Garbage on HardwareSerial port 3.0.4 , whereas 3.0.0 works fine.

Sketch

#include <FuGPS.h>
#define SERIAL2_TX 16
#define SERIAL2_RX 18
#define BAUDRATE_GPS 460800

#include <HardwareSerial.h>

HardwareSerial SerialPort1(1); // use UART1

FuGPS fuGPS(SerialPort1);
bool gpsAlive = false;

void setup()
{
    SerialPort2.begin(BAUDRATE_GPS, SERIAL_8N1, SERIAL2_RX, SERIAL2_TX); 
   Serial.begin(115200);
  delay(1000);
}

void loop()
{
  //   Valid NMEA message
    if (fuGPS.read())
    {
        // We don't know, which message was came first (GGA or RMC).
        // Thats why some fields may be empty.
gpsAlive = true;

        Serial.print("Quality: ");
        Serial.println(fuGPS.Quality);

Debug Message

hecksum is invalid
�NR�G,p84025,200,A(5075l11r05r(Nh01427,05;144,E(0.00v(1v6.r1,p50824(,,�,V,30    `GN�HLh10v5.311051(N,01667.05z14t(Eh08p023.200,�,A,45   `GN�PGh17t.13,T(,M(0.003(N,0.p06hO,�.2t GN�G�(0x00t1.v00(5075.311051(N,01t67l05z14r,E(1,45,0.67,571l1,�(4v.6hM,(
State: 0
Invalid NMEA message (missing $, * or <CR>
State: 39
Checksum is invalid
G�VT�,172.15,P,hI,p.0p7,�,0,003,K(A45 GN�GA(080023.500h10v1.r11p51(N,01647.05914r(Eh1,t1,p.67,571.3,M(43,6,�,h.7
State: 0
Invalid NMEA message (missing $, * or <CR>
State: 0
Invalid NMEA message (missing $, * or <CR>
State: 0

Other Steps to Reproduce

No response

I have checked existing issues, online documentation and the Troubleshooting Guide

• [X] I confirm I have checked existing issues, online documentation and Troubleshooting guide.

[lbernstone]

Code does not match the output. This looks like you have a line where you are printing a String, but the function expects a char* (or vice-versa).

[Jason2866]

With latest refactor of the hardware serial speed settings, there are speeds possible way of the expected. We (Tasmota) have seen 115942 instead of 115200 with an ESP32. Probably related to the changes done to solve the issues with light sleep.

[SuGlider]

With latest refactor of the hardware serial speed settings, there are speeds possible way of the expected. We (Tasmota) have seen 115942 instead of 115200 with an ESP32. Probably related to the changes done to solve the issues with light sleep.

This is correct. We changed UART to use TICK REF as clock source, instead of APB. TICK REF is a 2MHz steady signal that doesn't change if APB changes, therefore, it won't change if CPU Freq is changed. This is useful for a future feature that we will include in Arduino called DFS, which may reduce the frequency of the CPU automatically whenever no task is in the running state.

DFS would translate into energy efficiency and low power.

Today we had an internal talk about it. We are considering removing ESP32 and ESP32-S2 from this future feature. Both are old and have no good hardware features to allow Arduino to run in low power mode using DFS.

In such case we will roll back the UART source clock change just for the ESP32 and ESP32-S2. We would also move forward with low power DFS (Dynamic Frequency Scaling) only for the ESP32-C3, ESP32-S3, ESP32-C6, ESP32-H2 and ESP32-P4 (future).

this approach would also solve this issue

@olagt @Jason2866 and @lbernstone - do you have any opinion about the above?

[lbernstone]

@SuGlider Well, do what is necessary to get DFS to work.

[SuGlider]

@SuGlider Well, do what is necessary to get DFS to work.

Mainly most peripherals, and mainly UART, shall use a source clock that doesn't change when APB frequency changes, otherwise, it will not allow the SoC to reduce automatically the CPU frequency in order to reduce power consumption. Other than that, it is necessary to enable it in the skdconfig and add proper "Arduinish API".

[Jason2866]

@SuGlider A while ago tried changing MCU clock with the ESP32, resulted in sometimes! wifi issues. Maybe a good idea not to do DFS with the ESP32 / ESP32-S2? Anyways UARTs and probably most uses cases are working being a bit of. No need to do it different for the ESP32/ESP32-S2

[dl9rdz]

I have a similar problem on the (rather old) TTGO LoRa32 v1 board.

Very simple sketch

void setup() {   Serial.begin(115200);   }
 void loop()  {
    Serial.print("Hello");    delay(500);
    Serial.println(" world!");     delay(500);
}

Works fine e.g. on TTGO LoRa32 v2.1.6 or T-Beam 1.0/1.1, but prints garbage on the older LoRa32 v1 board.

(If I set the terminal on the PC to 74880 baud instead of 115200 baud I get the Hello world instead of the garbage)

Edit: esptool chip_id on TTGO LoRa32 v1 board: Chip is ESP32-D0WDQ6 (revision v1.0) Crystal is 26MHz

Working boards: T-Beam: Chip is ESP32-D0WDQ6 (revision v1.0) Crystal is 40MHz LoRa32 v2.1.6: Chip is ESP32-PICO-D4 (revision v1.0) Crystal is 40MHz

So this seems to be related to the clock frequency. Indeed building for the heltec_wifi_lora_32 board instead of ttgo-lora32-v1 board fixes the problem (even if it is not a Heltec board)...

[lbernstone]

I have a similar problem on the (rather old) TTGO LoRa32 v1 board. Edit: esptool chip_id on TTGO LoRa32 v1 board: Chip is ESP32-D0WDQ6 (revision v1.0) Crystal is 26MHz

26MHz crystal has been deprecated. This is known, and AFAIK will not be fixed. You will have to stick with old versions of arduino or roll your own libraries.

[Jason2866]

adding #define F_XTAL_MHZ 26 at the beginning of the sketch should switch to the needed 26Mhz clock frequency.