Using Serial.begin() more than one time crashes

[VisualMicro]

Describe what is failing

Using Serial.begin(baud) twice crashes the ESP32 Dev Board

Arduino ESP32 Dev Board from this package:-
https://raw.githubusercontent.com/espressif/arduino-esp32/gh-pages/package_esp32_dev_index.json

Show the shortest possible code that will duplicate the error

void setup()
{
  Serial.begin(115200);
  Serial.print("Hello World");
  Serial.begin(115200);
}

void loop() {}

Show the EXACT error message (it doesn't work is not enough)

Hello Worldets Jul 29 2019 12:21:46

rst:0x8 (TG1WDT_SYS_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0030,len:1412
load:0x40078000,len:13400
load:0x40080400,len:3672
entry 0x400805f8

[lbernstone]

Please follow the issue template and indicate which device and version has the issue. 2.0.0alpha seems to have some problems in HardwareSerial. Even initializing two uarts causes a crash. Does not occur in esp32-s2 (@me-no-dev)

[VisualMicro]

Please follow the issue template and indicate which device and version has the issue. 2.0.0alpha seems to have some problems in HardwareSerial. Even initializing two uarts causes a crash. Does not occur in esp32-s2 (@me-no-dev)

Sorry, I have added a link to the latest arduino-esp32 json, the crash info from the Serial Monitor and made a clearer statement of the issue.

The two serial issue you mention might be related. Will leave it with you. Let me know if you need anything else. Thanks

[me-no-dev]

confirmed

[pgrawehr]

Just observed a very similar issue. It does not crash, but fails to work after the second Serial.begin(). Try this simple sketch:

void setup() {
  // initialize serial:
  Serial.begin(115200);
  // Serial.begin(115200); // If this line is uncommented, Serial.available() will always return 0. 
}

void loop() {
  // if there's any serial available, read it:
  while (Serial.available() > 0) {
    Serial.print("There's some data: ");
    // look for the next valid integer in the incoming serial stream:
    int red = Serial.read();
    Serial.println(red, HEX);
  }
  // Serial.print("I'm still alive"); // Enable this to see that the board does not crash
}

If the program is run with the second Serial.begin() commented out, everything works as expected and the sketch prints the hex values of whatever it gets over the serial console. If the line is enabled, nothing is ever printed. But the board is not dead, as can be shown by uncommenting the last line, which keeps being printed.

In case it matters, this is with the released version 1.0.6.

[sansillusion]

Why would anyone run serial.begin() twice ?

[pgrawehr]

@sansillusion In my particular case, I have a quite complex library, and I haven't found out where exactly the second call comes from, but it seems to happen while executing a software reset command (initiated over the serial communication). The library compiles and runs flawlessly on other boards. A more common case would be if you want to dynamically change the baudrate.

[pgrawehr]

Update: While the above finding is still true (it reproduces easily), my problem was actually caused by setting the state of GPIO 1 and 3 to output during a software reset. Apparently, these two logical lines are used for the USB Uart and should not be touched. So I found a bug that wasn't even the cause of my problems...

[stale]

[STALE_SET] This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs. Thank you for your contributions.

[VojtechBartoska]

keeping this open

[stale]

[STALE_CLR] This issue has been removed from the stale queue. Please ensure activity to keep it openin the future.