UART Communication problems at 921600

ESP_Faye
Posts: 25
Joined: Thu Dec 10, 2015 6:47 am

Re: UART Communication problems at 921600

Postby ESP_Faye » Wed Nov 13, 2019 7:00 am

Crypth wrote:
Mon Nov 11, 2019 5:23 pm
Is there any chance the AT library will end up open to the public?


Sorry that AT lib is not open source, and maybe it will not change to open source in the future. Sorry for the inconvenience.

ESP_houwenxiang
Posts: 118
Joined: Tue Jun 26, 2018 3:09 am

Re: UART Communication problems at 921600

Postby ESP_houwenxiang » Thu Nov 14, 2019 7:40 am

LukeSkyWire wrote:
Wed Jun 20, 2018 11:05 am
What I have noticed however is if I send 1400 bytes the uart_read_bytes returns a value in the range of 1390.
If I send 600 bytes I get a len of approx 596.
Hi, LukeSkyWire

Have you enabled hardware flow control? At 1M baud, the CPU can read out the data in fifo in time. But At 2M baud-rate, the CPU cannot read out the data in fifo in time, resulting in data loss. When enable the flow control, the baud-rate can reach 5M.

thanks !!
wookooho

Crypth
Posts: 3
Joined: Tue Oct 29, 2019 12:24 pm

Re: UART Communication problems at 921600

Postby Crypth » Thu Nov 14, 2019 5:06 pm

ESP_Faye wrote:
Wed Nov 13, 2019 7:00 am
Crypth wrote:
Mon Nov 11, 2019 5:23 pm
Is there any chance the AT library will end up open to the public?


Sorry that AT lib is not open source, and maybe it will not change to open source in the future. Sorry for the inconvenience.
That's all right with me if we could get it working without errors in the uart communication.

I'm in the process of setting up HW control.
When compiling IDF and AT with 8,0,1,3, it doesn't seem to change anything at all. It chatters like it's not set after a reset.
When we send the UART_CUR command with HW control, the behavior changes radically.
Are we supposed to change the HW control on the host side after we send the UART_CUR changes to HW control, not from start?
IoT hacking all night long.

User avatar
gunar.kroeger
Posts: 143
Joined: Fri Jul 27, 2018 6:48 pm

Re: UART Communication problems at 921600

Postby gunar.kroeger » Mon May 25, 2020 5:47 pm

ESP_houwenxiang wrote:
Thu Nov 14, 2019 7:40 am
LukeSkyWire wrote:
Wed Jun 20, 2018 11:05 am
What I have noticed however is if I send 1400 bytes the uart_read_bytes returns a value in the range of 1390.
If I send 600 bytes I get a len of approx 596.
Hi, LukeSkyWire

Have you enabled hardware flow control? At 1M baud, the CPU can read out the data in fifo in time. But At 2M baud-rate, the CPU cannot read out the data in fifo in time, resulting in data loss. When enable the flow control, the baud-rate can reach 5M.

thanks !!
Is this the official maximum baudrate achievable without hw flow control? Could you link the documentation specifying this limit? I only remember seeing the 5M limit and no requirement for hw flow control connections mention, but I could be wrong.
I'm also trying to get the maximum throughput with uart using the events example, but getting fifo overflow events
"Running was invented in 1612 by Thomas Running when he tried to walk twice at the same time."

saigajul37
Posts: 7
Joined: Tue Apr 27, 2021 12:07 pm
Location: pune

Re: UART Communication problems at 921600

Postby saigajul37 » Wed May 12, 2021 7:57 am

Hi everyone,
I am using esp-idf v3.3.
Esp32 clock frequency set to 240 MZ

I am facing the same issue, the following is my code flow and code. It's a very simple code.
Code flow
1) send command
2) wait till all data received in rx_buff of UART driver
3) Once all data received in rx_buff read that data into a local variable.
4) proccess recivied data.
5) repeat everything from point no. 1
still get data missing randomly at any time

Code: Select all

	

#define UART_NUM			(UART_NUM_1)
#define BAUD_RATE			(921600)
#define RX_BUF_SIZE			(100000)

void uart_Init()
{
	const uart_config_t uart_config = {
			.baud_rate	= BAUD_RATE,
			.data_bits	= UART_DATA_8_BITS,
			.parity		= UART_PARITY_DISABLE,
			.stop_bits	= UART_STOP_BITS_1,
			.flow_ctrl	= UART_HW_FLOWCTRL_DISABLE
	};

	uart_param_config(UART_NUM, &uart_config);
	
	uart_intr_config_t uart_intr = {
	.intr_enable_mask = UART_RXFIFO_FULL_INT_ENA_M
	| UART_RXFIFO_TOUT_INT_ENA_M
	| UART_FRM_ERR_INT_ENA_M
	| UART_RXFIFO_OVF_INT_ENA_M
	| UART_BRK_DET_INT_ENA_M
	| UART_PARITY_ERR_INT_ENA_M
	| UART_GLITCH_DET_INT_ENA_M,
	.rxfifo_full_thresh = 1, //-----> changed it from 1 to 64 still data missing
	.rx_timeout_thresh = UART_RX_TOUT_THRHD,
	.txfifo_empty_intr_thresh = UART_TXFIFO_EMPTY_THRHD
	};

	uart_intr_config(UART_NUM, &uart_intr);	

	uart_set_pin(UART_NUM, TX_PIN, RX_PIN, UART_PIN_NO_CHANGE, UART_PIN_NO_CHANGE);

	esp_err_t ret = uart_driver_install(UART_NUM, RX_BUF_SIZE, 0, 5, &uartQueueHandle, 0);

	if (ret!== ESP_OK) {	
		systemRestart();
	}
	uart_flush(UART_NUM_1);
}

void serial_read(void *arg) 
{
uint8_t* dataSerial = (uint8_t*) malloc(dataSize);


uint32_t read_buff_size = 49000;
size_t b_len =0;

uint8_t * rx_data = (char *) heap_caps_malloc(read_buff_size, MALLOC_CAP_SPIRAM);
 	
  	while ( 1 ) 
	{
		
		send_cmd();
		while( ( b_len < read_buff_size ) &&  ( time_out < 20 ) ) 
		{
			ESP_LOG_BUFFER_HEXDUMP("HEXDUMP", cmd_struct.cmd_buff,cmd_struct.config.cmd_len, ESP_LOG_INFO);

			ESP_LOGI(SCANNER_TAG, "b_len  : %d", b_len);

			uart_get_buffered_data_len( UART_NUM, &b_len );

			TIMERG0.wdt_wprotect=TIMG_WDT_WKEY_VALUE;
			TIMERG0.wdt_feed=1;
			TIMERG0.wdt_wprotect=0;
			
			msDelay(1000);
			
			time_out++;
		}
		uart_read_bytes(UART_NUM, &rx_data, read_buff_size, 0)
		processdata(rx_data);
		msDelay(1);
    }
    vTaskDelete(NULL);
}    	

void app_main(void)
{
	uart_Init();
	while ( isuart != pdPASS)	{	// wait till task is created 
		
	isuart = xTaskCreatePinnedToCore(serial_read, "serial_read", 1024*12, NULL, 22, &scanner_t, CORE_ONE);
		ESP_LOGI(NIBLEWAY_ONLINE, "scanner Task, pdFAIL");

			msDelay(100);
	}
}
Sainath Gajul

Who is online

Users browsing this forum: No registered users and 61 guests