"Serial.available()" does not work after update to "Update IDF to 9a26296" from Sep 12, 2017

[xterminos]

Hardware:

Board: ESP32 Dev Module
Core Installation/update date: 12/jul/2017
IDE name: Arduino IDE 1.84
Flash Frequency: 80Mhz
Upload Speed: 921600

Description:

As far as I can see "Serial.available()" no longer works after I updated to "Update IDF to 9a26296" from Sep 12, 2017. As soon as I try to send some chars from the arduino-serial-monitor the sketch hangs!

Sketch:

This is a slightly modified "SerialEvent"-Example from the Arduino-IDE built-in examples.

String inputString = "";         // a String to hold incoming data
boolean stringComplete = false;  // whether the string is complete

void setup() {
  // initialize serial:
  Serial.begin(115200);
  // reserve 200 bytes for the inputString:
  inputString.reserve(200);
}

void loop() {
  // print the string when a newline arrives:
  if (stringComplete) {
    Serial.println(inputString);
    // clear the string:
    inputString = "";
    stringComplete = false;
  }

  serialEvent(); //manually calling "void serialEvent()"

  Serial.print("loop: "); Serial.println(millis()); //just to show some activity on the serial monitor.

}

/*
  SerialEvent occurs whenever a new data comes in the hardware serial RX. This
  routine is run between each time loop() runs, so using delay inside loop can
  delay response. Multiple bytes of data may be available.
*/
void serialEvent() {

  Serial.println("serialEvent"); //show that "void serialEvent()" is really called every loop.

  while (Serial.available()) {

    Serial.println("inside: \"while (Serial.available())\""); //sketch never reaches this point!

    // get the new byte:
    char inChar = (char)Serial.read();
    // add it to the inputString:
    inputString += inChar;
    // if the incoming character is a newline, set a flag so the main loop can
    // do something about it:
    if (inChar == '\n') {
      stringComplete = true;
    }
  }
}

Debug Messages:

none

[Outersite]

I have a similar/same problem. I am new to ESP32 (just downloaded from GIT yesterday) and trying to migrate a working sketch from ESP8266. The sketch hangs (but does not crash) either in serial.available or serial.read (which no doubt calls available). It looks like a locking problem as if HAL locks are disabled it does not hang (but fails to find anything in the queue).

[Outersite]

As an update to my previous post, I went back to one commit prior to the "Update IDF to 9a26296" commit and serial.available still fails. I have now rolled back to 9th September commit and serial.available() is working OK. I am using Adafruit Feather ESP32 , Arduino IDE 1.8.2.

[xterminos]

@Outersite
Thank you for your comments and your confirmation. I retested it, with my example-sketch (and with my real project), with the following results:

"serial.available()" works ok with the commit from Sep 11, 2017, ("add Microduino-esp32 (#621)", Tree: 0bce98e).

"serial.available()" FAILS, (sketch hangs), with the commit from Sep 12, 2017, ("Update IDF to 9a26296", Tree: ba929be).

But maybe I have missed something or there is another bug that affects your current project.

[me-no-dev]

Fixed!!! e2bd93c

[xterminos]

@me-no-dev
First of all: Thank you very much for spending your time on this issue!

But I am sorry to tell you, that the Bug still persists, the sketch still hangs when using "serial.available()"!

I cleaned up everything, but no luck at all! I will try again later.

[me-no-dev]

but I so tested this ;) my Serial now works fine:

void loop(){
  while(Serial.available()) Serial.write(Serial.read());
}

[xterminos]

@me-no-dev
Sorry to bother you again. But this is still not working for me with "Tree: d27d297"!
I tried it with a Dev-Board, there it failed every time. And I tried it with a "pure" ESP32-WROOM-32" (with an external usb-to-serial-adaptor), there it worked once within twenty uploads.
With "Tree: 0bce98e" everything works flawlessly on both boards.

Is there anything wrong with the following Test-Sketch? This works without problems on "Tree: 0bce98e", but leads now to constant reboot on "Tree: d27d297".

uint32_t while_loop_count = 0;
uint32_t loop_count = 0;

void setup() {
  Serial.begin(115200);
  delay (1000);
  Serial.println("Serial Port ok!");
}

void loop() {


  Serial.print("loop_count: "); Serial.println(loop_count);

  while (Serial.available())
  {
    Serial.print("inside while_loop_count, got: ");

    Serial.write(Serial.read());

    Serial.println();

    while_loop_count++;
  }

  loop_count++;

  delay (500);
}

[me-no-dev]

I will replace the serial driver with the one in IDF and we will see how things will go. I need to do it anyway and there were some changes in IDF that are probably causing this.

[xterminos]

@me-no-dev
Thank you very much for not forgetting this issue!
I see that the ESP32, as little and cheap it may be, with its two cores and its RTOS, is a very complex system, and that it needs needs a lot of work and time to release all its features in a pleasing way to the public (the Arduino-Users).
I hope you had a good weekend and could let go the ESP32-stuff for a little while!

[me-no-dev]

Visited the Great Wall and the Forbidden City in Beijing, so surely I had a great weekend! Long dream of mine :) Will try to replace the driver this week if nothing major comes in between

[xterminos]

Impressive!
...
Sounds allright for me! Will for sure have a look on the next couple of releases and do some thoroughly testing.

Thank you and good luck!

[me-no-dev]

Please pull the latest changes and report :) Thanks!

[xterminos]

@me-no-dev
Sorry for letting you wait.
The good news is: All the basic serial-input-stuff seems to work again as expected, on all boards, without hangs or resets! Thank you for that!

This means we are now able again to send serial-data or serial text-commands, of reasonable and preferably predefined max-length, from the arduino-console to the ESP32. I guess this is what most arduino-users will use the ESP32-Serial-Input for.
...
But, in one of my bigger ESP32-projects, I had a simple serial-file-upload-routine, that let me wrote binary-files of undefined length (*.bmp, *.jpg, *.raw) to an SD-Card on the ESP32. This routine no longer works as it did before with "Tree: 0bce98e", it now always writes/receives much less bytes than it should.
Maybe my serial-file-upload-function is just badly written and "Tree: 0bce98e" was just more forgiving than the current release. I have to do some deeper research. Until I can fix it or break it down to a smaller understandable example there is nothing I could add to this thread that would be of any further help...

So, thank you very much again and have a good day!

[me-no-dev]

Actually very little changed in the Serial driver. It is basically how the interrupt is defined, and not to check serials hat are not enabled. Everything else is the same. I imagine you might just need to read from serial more often, so you can get the data in smaller chunks, but really none of that changed between the versions.

[xterminos]

Thank you for your advice.
Yes I guess it was sheer luck that it worked before. We can not assume a precisely predictable write-timing behavior of every SD-Card that is out there.

[muktillc]

I am using the most recent version and for me serial read and serial available is still not working. I wanted to send a string of characters to ESP32.

[xterminos]

@muktillc
I am sorry but I can not confirm this.
I tested all my "weird" serial-stuff and everything worked as expected!
I tested on Tree: 126674c from Oct 30, 2017.

Keep in mind, that the esp32 unlike "normal" Arduinos has a real operating-system which is very unforgiving if you try to read or write from or to "forbidden" memory-locations and this can happen very easily!
At the beginning I often had all kinds of strange bugs with character-arrays and loops.
Programs that allways worked flawlessly on every normal Arduino did silly things on the esp32.
For example: Your loop counts to 100 and everything is ok, ... your loop counts to 101 -> strange things happen! I then assumed everything, even a damaged esp32. But the culprits always were wrong indexes when I tried to access buffers or char-arrays, one Byte can make the difference between success and debugging-hell.

[muktillc]

Finally. Got it working.

…

On Sun, Nov 5, 2017 at 6:15 AM, xterminos ***@***.***> wrote: @muktillc <https://github.com/muktillc> I am sorry but I can not confirm this. I tested all my "weird" serial-stuff and everything worked as expected! I tested on Tree: 126674c <126674c> from Oct 30, 2017. Keep in mind, that the esp32 unlike "normal" Arduinos has a real operating-system which is very unforgiving if you try to read or write from or to "forbidden" memory-locations and this can happen very easily! At the beginning I often had all kinds of strange bugs with character-arrays and loops. Programs that allways worked flawlessly on every normal Arduino did silly things on the esp32. For example: Your loop counts to 100 and everything is ok, ... your loop counts to 101 -> strange things happen! I then assumed everything, even a damaged esp32. But the culprits always were wrong indexes when I tried to access buffers or char-arrays, one Byte can make the difference between success and debugging-hell. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#645 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/Aetc8DVp4Iiwn3WXOBK_f4CAZ1HfQZ_Yks5szZjDgaJpZM4PdLU4> .