Posts: 1
Joined: Wed Oct 18, 2017 3:03 pm


Postby Roody75 » Wed Oct 18, 2017 4:18 pm

My setup:
ESP32 using UART1 @300Baud 7E1
ESP-IDF Version 2.1

I need the ESP-WROOM-32 UART to inform the application as soon as possible after a pending transmission has finished for transmitter enable/disable purposes as well as baudrate switching, echo/collision detection and so on. Therefore I read this forum and found some interesting stuff about RS485 support and tried to apply this to the esp-idf driver/uart.c (as recommended in RS-485 support).

Unfortunately the changes doesn't work so far. I see that the according (txen-) portpin changes the level to high as soon a transmission is started, but will not last until the whole telegramm is sent. Instead it looks always like this (yellow=TX data, blue=TXEN-signal):


As you can see, the deactivation of the TXEN-signal happens right before the first bit (startbit) is sent. After a deeper look into the uart.c I found, that the UART_TX_DONE_INT is used for this purpose. So I tried several combinations where this interrupt was enabled in application, in the UART_TXFIFO_EMPTY_INT or according to the current FIFO buffer content size in the ISR. I tried to not disabling it in the ISR or simply toggle the GPIO-Pin to see it occur. Anyway, all changes / tests made, lead to the same strange behaviour: This interrupt is called only once right BEFORE a transmission is startet and never again after that regardless of its interrupt-enable settings or the remaining UART fifo-content.

I verified this by using the original driver sources (esp-idf/component/driver/uart.c) and the function uart_wait_tx_done() (This function is triggered by the same interrupt via an RTOS semaphore) and the described issues happens here as well.

I now implemented a workaround by polling UART[uart_num]->status.st_utx_out and waiting (via vTaskDelay(1)) until it gets 0 (IDLE) after a transmission has started. This seems to work though it's quite unsafe for higher baudrates or during heavy system load.

Are you aware of any issues regarding the UART_TX_DONE_INT and if so, is there some workaround? Could it be a glitch in documentation?

Posts: 27
Joined: Thu Sep 07, 2017 10:26 am


Postby humptydumpty » Wed Nov 01, 2017 12:20 am

I use the UART_TX_DONE_INT successfully in my application with no issues such as you describe.

I only enable the interrupt after filling the UART buffer, i.e. after transmission is already started.

Who is online

Users browsing this forum: No registered users and 5 guests