Tasmota crashes on ESP32-PICO-V3 with recent core

[barbudor]

Hi
I can't report this as an issue because I unfortunately can't provide more qualified information but I'm facing a problem with Tasmota on ESP32-PICO-V3.
I'm using Tasmota with a driver for the french national electricity meter called Linky. The driver is meant to receive frames on a UART, decode them and feed the energy information to Tasmota's internals for publication.
The driver has been unchanged for months and until recently my Tasmota build with this driver was working fine on either ESP32-D0WDQ6 (mini-D1-ESP32) and on ESP32-PICO-V2.
The last version that was working fine on the PICO was using what @Jason2866 is calling Core/SDK 2_0_2_2/v4.4-3-g6afb23d90a. This frozen Core/SDK was in Tasmota since early February.
2 days ago, Jason's upgraded the Tasmota Core/SDK to 2_0_2_3/v4.4-2.0.2-420-g4ff9ceb19a which he describe as "based on latest IDF44 commit and latest commit of Arduino branch esp32-s3-support".

The problem occurs as soon as I enable the Teleinfo driver which uses either UART1 or UART2 and the ESP crash with a Guru Meditation, Load Prohibited.
It doesn't seem to matter which GPIO are used for the UART. It doesn't even need to actually receive serial data.
The same binary works fine on ESP32-D0WDQ6.
Previous binaries were working well on both boards.
I tested a few other drivers that are using serial and they don't create such problem.

I'm sorry for not being able to provide more details but I thought it was worth to drop a note there.
Thanks for the hard work.

[me-no-dev]

@SuGlider PTAL. @barbudor which pins and serial are actually being used? PIVO-V3 has some IOs changed.

[barbudor]

I have tested with quite a few pins.
My board for this as the serial incoming on GPIO8 and this have been working fine on the PICO-V3 with previous core.
With this new core, the crash occurs whatever pin I'm using for the serial RX. I tested GPIO8, 13, 15, 23, 27, 33 just to be sure.
the UART used are either UART1 or UART2

[me-no-dev]

it is important to see your code flow on starting and using the UARTs. We made some changes to APIs internally and want to see if there is a case we didn't think of.

[Jason2866]

It is related to the UART refactoring which generates Timer Group1 Watch dog reset digital core
after reverting the Arduino UART to a older version no more WDTs. Idk what is the reason for the WDTs
The used working UART version is https://github.com/tasmota/arduino-esp32/commits/revert_uart
Strange that this problem nearly never occur with a standard ESP32, and always with the PICO-V3-02

[SuGlider]

@Jason2866 @barbudor

I have analyzed the issue here reported.
I have a question...

Is it possible that Serial1 or Serial2 are being initialized not passing TxPin to SerialN.begin()
Something like this: Serial2.begin(9600, SERIAL8N1, GPIO5); for example?

Please let me know. Thanks.

[SuGlider]

Yes, Found it...

https://github.com/Jason2866/Tasmota/blob/development/tasmota/xnrg_15_teleinfo.ino#L584-L666

Apparently it only sets up rxPin, leaving txpin as -1

[SuGlider]

The last commit to Arduino HardwareSerial I made I changed it to force the default RX/TX pin when in the very first begin() any of them is -1.

Before that, HardwareSerial was only setting the default pins only if BOTH were -1... that's the issue.
I'll prepare a FIX to roll back this specific behaviour, in order to allow a RX only case such as Teleinfo.

[barbudor]

Thanks a lot @SuGlider 🙏
Still why would forcing the pins to default would lead to a crash ?
What are those default pins ?

[Jason2866]

Thank you @SuGlider Why does the crash only happen with the Pico V3-02 ?
Are the default pins different?

[SuGlider]

Thanks a lot @SuGlider 🙏 Still why would forcing the pins to default would lead to a crash ? What are those default pins ?
Thank you @SuGlider Why does the crash only happen with the Pico V3-02 ?
Are the default pins different?

HardwareSerial.cpp defines pins 9 and 10 (rx/tx) for Serial1 and pins 16 and 17 for Serial2, as default pin setup.
Pins 9 and 10 are used in Flash in QIO mode. Thus in order to use these pins, ESP32 must be in DIO mode.
Pins 16 and 17 are free on the ESP32-D0WDQ6, but not in the ESP32-PICO, because they are used internally.

The default pins are used with something like Serial2.begin(baudRate); - in such case, GPIO default for TX and RX shall be initialized and set.

By other hand, Serial2.begin(baudRate, mode, rxPin, txPin) would be fine - using those pins in the UART setup.

The issue comes with something like Serial2.begin(baudRate, mode, rxPin) that is valid since Arduino version 1.0.6, but doesn't say what to do with txPin... or not passing rxPin like in Serial2.begin(baudRate, mode, -1, txPin).
The correct behaviour, when only defining one of the pins, shall be to set Tx or Rx pins to their defaults - this is the last commit to Github.

So with TELEINFO, it would set RxPin and leave TxPin as -1.
In ESP32-PICO, default for TxPin would be 10 or 17 (for Serial1 and Serial2).
BUT, Pin 10 is used in DIO Flash mode and Pin 17 is used internally and can't be used.
Thus, Arduino will initialize GPIO pins that are invalid to be used in UART, leading to a crash.

Each esp32 Package is different:

PICO-3: Pins 9 and 10 in the table are used to drive Flash in QIO mode. Pins 16 an17 are not available.
https://docs.espressif.com/projects/esp-idf/en/latest/esp32/hw-reference/esp32/get-started-pico-kit-1.html#get-started-pico-kit-1-pin-notes

Here we see this message written about pins 9 (D2), 10 (D3), 16 and 17:
The pins D0, D1, D2, D3, CMD and CLK are used internally for communication between ESP32 and SPI flash memory. They are grouped on both sides near the USB connector. Avoid using these pins, as it may disrupt access to the SPI flash memory / SPI RAM.

The pins GPIO16 and GPIO17 are available for use only on the boards with the modules ESP32-WROOM and ESP32-SOLO-1. The boards with ESP32-WROVER modules have the pins reserved for internal use.
https://docs.espressif.com/projects/esp-idf/en/latest/esp32/hw-reference/esp32/get-started-devkitc.html

About PICO-4: https://docs.espressif.com/projects/esp-idf/en/latest/esp32/hw-reference/esp32/get-started-pico-kit.html#get-started-pico-kit-v4-pin-notes
Pins 6, 7, 8, 11, 16 and 17 are connected to the flash pin of ESP32-PICO-D4

[SuGlider]

I'll research about what happens whether txPin is undefined and the application tries to execute Serial.write()...
Would it break Tasmota in TELEINFO mode?

That may determine what we shall also do with the Arduino implementation...

[barbudor]

@SuGlider thanks for the explication
It may also explain why I was seeing some littlefs error directory corruption message before the crash.
For some reasons, @Jason2866 were not seing it but he was using a different build options, so mapping of code in flash could differ.

Teleinfo driver will never try to send data to the uart.
There are probably other smart-meter drivers in Tasmota that also set TX pin to -1. All access to serial port in Tasmota must go through the TasmotaSerial wrapper. So if belt and braces are needed, we could add some protection code in our TasmotaSerial wrapper so the send functions get ignored if TX pin was set to -1.

[Jason2866]

With the explanation it is clear what happened. Thx again. Without PSRAM Gpios where used which did not conflict. As @barbudor wrote for Tasmota we could add protection code to avoid invalid Gpio mappings.
Imho, to avoid issues for all users, this should be solved in Arduino code. There are for sure more users needing only RX from the UART and TX is left untouched.

[SuGlider]

PR #6394 shall solve the issue.
@barbudor @Jason2866 - Could you please apply this PR and check if this solves this discussion?
Thanks!

[Jason2866]

@SuGlider @barbudor can do a test tomorrow evening. I builded already the framework