uart_wait_tx_done() returns without waiting

[Jami17]

uart_wait_tx_done() does not wait but returns immediately under certain conditions.
It works when using it in another task, but fails when using it in the same thread that received a uart-message and then sends a uart-reply (15 bytes)

For a halfduplex RS485 I use this:
TX_ENABLE;
uart_write_bytes()
uart_wait_tx_done()
RX_ENABLE;

Result: the line is already set back to RX even before the first bit gets sent.

It works when adding a 150us delay
TX_ENABLE;
uart_write_bytes()
delayUs(150); // extra delay
uart_wait_tx_done()
RX_ENABLE;


I am using: ESP-IDF v3.3-beta2-18-g0f927791b-dirty

[WiFive]

https://github.com/espressif/esp-idf/bl ... 1052-L1055

Maybe if the fifo hasn't been filled yet from the ringbuffer because of interrupt latency on the other core it will return immediately. So checking the fifo_cnt is not sufficient to determine whether the transmission is already done. The workaround would be only call uart_wait_tx_done on the core the interrupt runs on.

[Jami17]

I suspected the same. However I don't like the suggested workaround, too complicated. It would be wise that uart_write_bytes() sets a flag that only gets cleared when the data is moved to the ringbuffer. So wait_tx_done() waits also while that flag is set. For now the delayUs() works fine for me.

[biterror]

It seems this bug is still there in v4.2. I need to make sure I'm not sending out two modbus rtu packets end to end, but it doesn't seem so easy with almost nothing working as documented.. (Been fighting with the I2S driver for a long time just to find that the UART driver isn't much better. Getting frustrated.)

[Jami17]

Yes, the problem still is there, at least in the version dl'ed in March, not sure what version-no.

I recently varied the delay value
delayUs(150);

It worked down to 40us when the same core is used.
I have not tried to go lower to find out the limits.

It would be great so see this finally fixed.

[biterror]

It would also be nice if the driver supported inserting an idle period between transmitted packets (required by Modbus RTU mode, for example). The hardware supports this, but it requires driver support as well.