UART receives only in step by step debug

maurizio.scian
Posts: 14
Joined: Mon Jun 26, 2023 8:09 am

UART receives only in step by step debug

Postby maurizio.scian » Mon Jun 26, 2023 11:24 am

Hi all,
I have two UARTS, embedded with two 485 tranceivers.
Both the UARTS are able to send datas trough 485 tranceivers (data enable pin is correctly cabled). I tried to send some characters from the UART1 to UART2, but seems that UART2 don't receives the sent frame. But if work with debugger and execute uart_get_buffered_data_len routine step by step, finally returns the number of character inside the buffer, and i can easly get the buffer with uart_read_bytes. Both the UART owns their task, both the tasks have the same priority.

The uarts's configurations are really similar, both are configured as follow:

UART1:

Code: Select all

const int uart_num = UART_NUM_1;
uart_config_t uart_config = {
	.baud_rate = 19200,
	.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,
};
	
// Set UART log level
esp_log_level_set(TAG, ESP_LOG_INFO);

ESP_LOGI(TAG, "Start RS485 application test and configure UART.");

// Install UART driver (we don't need an event queue here)
// In this example we don't even use a buffer for sending data.
ESP_ERROR_CHECK(uart_driver_install(uart_num, BUF_SIZE * 2, 0, 0, NULL, 0));

// Configure UART parameters
ESP_ERROR_CHECK(uart_param_config(uart_num, &uart_config));

ESP_LOGI(TAG, "UART set pins, mode and install driver.");

// Set UART pins as per KConfig settings
ESP_ERROR_CHECK(uart_set_pin(uart_num, 17, 18, 8, UART_PIN_NO_CHANGE));

// Set RS485 half duplex mode
ESP_ERROR_CHECK(uart_set_mode(uart_num, UART_MODE_RS485_HALF_DUPLEX));

// Set read timeout of UART TOUT feature
ESP_ERROR_CHECK(uart_set_rx_timeout(uart_num, ECHO_READ_TOUT));
UART2 configuration is the same, but changes UART_NUM_1 to UART_NUM_2, and the pins (43, 44, 21 instead 17, 18, 8).
UART1 loop simply send a stream every second

Code: Select all

vTaskDelay(pdMS_TO_TICKS(1000));
printf("SEND!\r\n");
uart_write_bytes(uart_num, "CIAO\r\n", 6);
And UART2 loop simply checks and receive every second the buffer and print on the console

Code: Select all

vTaskDelay(pdMS_TO_TICKS(1000));
int length = 0;
ESP_ERROR_CHECK(uart_get_buffered_data_len(uart_num, (size_t*)&length));
printf("RECEIVED %d bytes\r\n", length);
if (length > 0)
{
	int len = uart_read_bytes(uart_num, Uart2RxBuf, length, (100 / portTICK_PERIOD_MS));
	if (len > 0)
	{
		uint16_t i = 0;
		while (len) {
			putchar(Uart2RxBuf[i]);
			len--;
			i++;
		}
	}
}
I use a loop of putchar because often (when i work step by step) UART2 receives has a 0 on the first character of the buffer (so if I use a printf it will print nothing).

I can grant that the hardware level works well (if don't, UART2 shouldn't receive anything, step by step debug or not), and I also checked the TTL stream on the UART2's RX pin.

With the micro in running, the console output is like that:

Code: Select all

SEND!
RECEIVED 0 bytes
SEND!
RECEIVED 0 bytes
SEND!
[...]
RECEIVED 0 bytes
SEND!
SEND!
RECEIVED 120 bytes
CIAO
CIAO
[...]
CIAO
But if i place a breakpoint in the uart_get_buffered_data_len and i execute step by step the routine, the output is like that:

Code: Select all

SEND!
RECEIVED 49 bytes
SEND!
CIAO
CIAO
CIAO
CIAO
CIAO
CIAO
CIAO
I really can't understand what is the problem... I also wrote in IDF discussion few hours ago. Thanks to all that will help me to resolve the problem!

MicroController
Posts: 1708
Joined: Mon Oct 17, 2022 7:38 pm
Location: Europe, Germany

Re: UART receives only in step by step debug

Postby MicroController » Tue Jun 27, 2023 1:03 pm

What's your value for "ECHO_READ_TOUT"?

You probably want to use the driver's events instead of sleeping+polling anyway.

maurizio.scian
Posts: 14
Joined: Mon Jun 26, 2023 8:09 am

Re: UART receives only in step by step debug

Postby maurizio.scian » Fri Jun 30, 2023 1:57 pm

MicroController wrote:
Tue Jun 27, 2023 1:03 pm
What's your value for "ECHO_READ_TOUT"?

You probably want to use the driver's events instead of sleeping+polling anyway.
ECHO_READ_TOUT is defined 3. It's not a problem of timeout.
I "solved" (not, really), i simply removed uart_get_buffered_data_len and all the application works. I don't understand, but seems that uart_get_buffered_data_len blocks the reception.

Who is online

Users browsing this forum: No registered users and 136 guests