Serial configuration ignored on ESP32 [RESOLVED]

Hi,

I have just come back to a project on Espruino that hasn't received any attention in the last past 6 months or so. I'm having a problem using code that worked on V1.97, V1.98 and V1.99 with Espruino V2.00 and V2.01.

Configuration of Serial3 (and maybe also Serial1 and Serial2) is being ignored. To come to this conclusion, I have produced the most simple code that exhibits the problem:

function send() {
	console.log("Sending...");
	Serial3.print("ZZZZZZZZZZZZ");
	setTimeout(send, 100);
}

function onInit() {
	Serial3.setup(115200);
	send();
}

Connecting a logic analyser showed the data was actually being transmitted at 9600 baud and sure enough, when I reconfigured the receiver to 9600 baud, I received the characters transmitted by the ESP32.

I also tried using 19200 baud but the output was still 9600 baud. To be certain I wasn't doing anything silly I have tried this code on the last version I believed it to work on (V1.99) and it does work.

I am using Serial1 for programming from the Espruino Web IDE so I have not been playing with it's configuration. I have ESP-WROOM-32s mounted on a PCBs so it's not so easy for me to change the pins used. The PCB layout expect Serial2 to be redefined to { tx: D25, rx: D34 } and I'm not getting anything on these pins so I believe that the pin selection is being ignored too.

I also seem to be experiencing related error messages. I occasionally see this message pop up in the console on V2.01 (not sure about other versions):

E (59292) uart: uart_read_bytes(1131): uart driver error

And every few minutes it will experience an error that causes it to reboot.

Sending...
Sending...
Sending...
/mnt/c/Users/rhys/esp32/V3.1/EspruinoBui­ldTools/esp32/build/esp-idf/components/f­reertos/queue.c:1441 (xQueueGenericReceive)- assert failed!
abort() was called at PC 0x40092f88 on core 0
Backtrace: 0x400962cb:0x3fff7080 0x40096423:0x3fff70a0 0x40092f88:0x3fff70c0 0x4017b331:0x3fff7100 0x400f6c24:0x3fff7150 0x400f8245:0x3fff7170
Rebooting...
ets Jun  8 2016 00:22:57
rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_d­rv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0018,len:4
load:0x3fff001c,len:2588
load:0x40078000,len:7192
load:0x40080000,len:5288
entry 0x40080278
E (29) boot: ota data partition invalid, falling back to factory
E (518) spiram: SPI RAM enabled but initialization failed. Bailing out.
WARNING: Bluetooth is disabled per ESP32.enableBLE(false)
Loading 2513 bytes from flash...
Running onInit()...
Sending...
Sending...
Sending...

Is this a known bug? Are there any work arounds?

Gary

No - this was not a known issue.
The change in the versions that work to it not working are changing the ide from esp-ide 2.x to 3.x
There is a recent release of 3.1.3 which I'm currently testing - this might sort the random rebooting.

I'm not sure if there will need to be changes to the serial driver to get the settings to work - @JumJum - any ideas?

We confirm this erroneous behavior, both with the 2.0 and the latest firmware.

To add some details: reception works OK on the speed configured (I tried 57600), but transmission happens at around 9600.

Maybe it is not exactly 9600, because it cannot receive itself with a simple loopback, but we continue to investigate this.

Arpad

Yes, that's an important detail that I missed from of my original post. I too am seeing that the ESP32 is able to receive ok. Thanks, Arpad.

Gary

Not sure if I stumbled upon something, but it appears as though a function call jshSetDeviceInitialised() is called inside the initConsole, but it is not within initSerial(). Does that explain why only console works as expected?

https://github.com/espruino/Espruino/com­mit/5dda6ae105a686d62f88ba05ad3e2f08276c­f79f#commitcomment-32900869

That definitely sounds like it would help. Maybe someone could try tweaking it and seeing if it fixes the problem?

I have tried version 2.02 and found that the problem has been fixed. Thanks everyone :)

Thanks for the update!