Using GPIO13/14/15 to connect UART2 caused kernel panic on T-ETH-Lite-ESP32

[sim0njo]

Hi,

I have an application with ESP32-WROVER that controls an RS485 bus via UART2, this works fine. I need WROVER because of PSRAM that my application requires.

Now I want to make a wired version of my design and try to use the T-ETH-Lite-ESP32 which has WROVER.

Since there is limitied free GPIO's I used GPIO13 for RTS (Data Enable), GPIO14 for RX and GPIO15 for TX. Please note that RTS line is pulled low with 10K resistor in my design to avoid RS485 bus lockup after power on of the ESP32.

I use a USB-to-TTL convertor to flash the ESP32 and to monitor the serial line, this convertor has Gnd/Gpio0/RST/TXD/RXD/3V3, sometimes when I open the COM% port to monitor ESP32 operation it shows correct output, and sometimes it shows garbled output and hangs the ESP32. In this case the BOOT button is not working anymore.

For now I boot the T-ETH-Lite-ESP32 in Wifi mode and this works ok, then I connect the RS485 bus connectors without powering the RS485 bus, so far no problem. When I power the RS485 bus, the slave devices start sending a boot msg, in response the ESP32 core 0 panics and reboots the ESP32.

The RS485 serial driver is interrupt driven and uses 2 timers (TIMER_0 and TIMER_1 in TIMER_GROUP_1).

Then I looked at the samples page and see that the RS485 master sample is not adjusted for T-ETH-Lite-ESP32... or do you mean that this module cannot run it (such as T-Internet) ???

I am confused, can somebody give me a hint.

thx Jo

[sim0njo]

After some experimenting.... disconnecting the Gpio0/RST pins on the USB-2-TTL convertor makes the T-ETH-Lite-ESP32 work more stable.

Still, when I try to start any software induced activity on the RS485 bus connected to UART_2, the module reboots.

Since my code is running for nearly 4 years on a WROVER, I conclude that I must look more closely to the T-ETH hardware design.

What are the advised GPIO's for setting up UART_2 on the T-ETH-Lite-ESP32 ???

[lewisxhe]

If it is ESP32, then the best available IO RX 33,39, 35,38,TX,33,32

0,2,4,13,14,15 are all ESP32 Strapping Pins. You need to understand the ESP32 pair before using it. Limitations on these Pins

https://www.espressif.com.cn/sites/default/files/documentation/esp32-wrover-e_esp32-wrover-ie_datasheet_en.pdf

[sim0njo]

Thank you for reminding me of the strapping pins of WROVER-E.

1) The document you refer to above (v1.9 dated 2023) shows following 5 strapping bits:

• GPIO05
• MTDO -> GPIO15
• GPIO02
• GPIO00
• MTDI -> GPIO12

2) Next I looked at the T-ETH-Lite-ESP32 schematic, there are just a limited amount of GPIO available on the module's pin headers and following GPIOs are used for the onboard SD connection:

• GPIO34 = SD_MISO, has TVS diode connected to GND
• GPIO13 = SD_MOSI, has TVS diode connected to GND and 10K pullup resistor
• GPIO14 = SD_SCK, has TVS diode connected to GND
• GPIO05 = SD_CS, has TVS diode connected to GND

3) GPIO32/33 are used for the I2C bus

4) Considering the fact that I have successfully used GPIO02 (as TX) and GPIO04 (as RX) in the past with a Zigbee coordinator SM-011, and GPIO14 for the RTS signal

5) I come to the conclusion that following combination should work:

• GPIO02 = RS485 TX
• GPIO04 = RS485 RX
• GPIO14 = RS485 RTS with 10K pulldown resistor, the TVS in place is removed by now to exclude interference

In this configuration my RS485 circuitry does not impact bootstrapping pins and the ESP32 operates correctly, I can enable the ethernet link and get an IP address, also the different server processes of my app startup (webserver, management interface, MQTT client, rule server, ...)

6) After all this, I got the RS485 working/crashing at random... till I finally decoded the crash backtrace to see an I2C call happening in the middle of my UART ISR. Aha !!!

Didn't I come short of GPIO pins for my 2 LEDs (red/blue) and replaced these with an I2C IO extender, where the red LED is used to indicate traffic on the RS485 bus. Aha again !!!

So I put the calls to set the LED state within an ISR in comment, and yes this fixed it.

[github-actions[bot]]

This issue is stale because it has been open for 30 days with no activity.

[github-actions[bot]]

This issue was closed because it has been inactive for 14 days since being marked as stale.