UART event queue full

[PointyPoint]

Hi everybody,
I'm using an ESP32 with IDF 5.4.1. I'm using all three serial ports: UART0 is for debug messages, UART1 is on an RS485 bus, and UART2 receives command. I'm mostly concerned about UART1 on the 485 mode.

I configure it quite simply:

Code: Select all

    uart_config_t poor_uart_config = {
        .baud_rate = 500000,
        .data_bits = UART_DATA_8_BITS,
        .parity = UART_PARITY_DISABLE,
        .stop_bits = UART_STOP_BITS_1,
        .flow_ctrl = UART_HW_FLOWCTRL_DISABLE,
        .source_clk = UART_SCLK_DEFAULT,
    };

    //Install POOR_UART_NUM driver, and get the queue.
    uart_driver_install(1, BUF_SIZE, 2048, 20, &my_queue, 0);
    uart_param_config(1, &poor_uart_config);

    uart_set_pin(17, 18, poor_rx, 27, UART_PIN_NO_CHANGE);
    uart_set_mode(1, UART_MODE_RS485_HALF_DUPLEX);

Then I put the queues into a set:

Code: Select all

    serial_queues = xQueueCreateSet(48);
    xQueueAddToSet(my_queue, serial_queues);
    xQueueAddToSet(my_queue2, serial_queues);

and then I have a task that blocks xQueueSelectFromSet, and responds to the event UART_DATA by putting the data into a ring buffer for further processing.

All is good and dandy, except if I unplug my serial adapter. If I try to transmit (no rx! only tx) on UART1 I start to get

Code: Select all

UART event queue full
UART event queue full
UART event queue full
UART event queue full

But there is nothing connected to my RX pin! Why am I getting this message? There should be nothing to receive at this point. Also, the UART_BREAK starts to get triggered.
So I thought about an electrical problem, maybe the floating pin is picking up data (!!)? But then, why don't I get UART_DATA events?
Also, once the "UART event queue full" message appears, I cannot properly write to the other two serials too, any communication attempt results in more "UART event queue full". So I modified uart.c to at least tell me which serial and what event:

Code: Select all

ESP_EARLY_LOGV(UART_TAG, "UART event queue full B %d nr %d", uart_event.type, uart_num);

(this is the message at line 1303. BTW shouldn't this be an ERROR log??) uart_event.type is always 0 (UART_DATA), and I get a message for each uart. But why don't I see my UART_DATA event in the event loop? If I wait a couple minutes to "cool off", and send data, I finally get some timid UART_DATAs, but then the systems reverts to "UART event queue full" until I reset.

So I tried switching off UART_MODE_RS485_HALF_DUPLEX and doing the RE-giggling by hand. Not optimal, but it works. In this modality I never get "UART event queue full" so I suspect there is something wonky happening when UART_MODE_RS485_HALF_DUPLEX is set. I tried the other two options: UART_MODE_RS485_COLLISION_DETECT and UART_MODE_RS485_APP_CTRL and the "UART event queue full" message disappears, but I get an enormous number of UART_BREAK events (also, I don't want collision detection or any mode where the header file says "(used for test purposes)").

Obviously I'm not going to use the serial port without the 485 transceiver connected, but I would also expect the system not to react into this destructive way, which to me is inexplicable.

[MicroController]

But there is nothing connected to my RX pin! Why am I getting this message? There should be nothing to receive at this point. Also, the UART_BREAK starts to get triggered.
So I thought about an electrical problem, maybe the floating pin is picking up data (!!)? But then, why don't I get UART_DATA events?

Yeah, a floating RX pin is a problem. Try and enable the internal pull-up on the pin.

[PointyPoint]

I checked with out hw engineer and rx is indeed pulled! My hunch here is that the auto 485 creates some problems with the serial fifos, because the fifo is full but I never get the UART_DATA event. If I disable the 485 mode and do it by hand, this problem disappeares.

[MicroController]

"FIFO is full" != "UART event queue full"
Break, framing errror != UART_DATA

Maybe ask the HW engineer what could be randomly pulling RX low or letting it 'undefined' in your scenario.