AT command answer too fast loosing start characters

[cjoecker]

Answers checklist.

• I have read the documentation ESP-AT Programming Guide and the issue is not addressed there.
• I have used the latest released firmware or have updated my ESP-AT branch (master or release) to the latest version and checked that the issue is present there.
• I have searched the issue tracker for a similar issue and not found a similar issue.

General issue report

I have a problem with the esp32 answering some commands and I don't get some of the start characters. For example, see the answering time of these logs for the serial communication:

16:28:04.321 --> AT
16:28:04.321 --> K

Here, the answer to AT should be OK but it is often responding just with K. It is happening with other commands also like AT+CIPSNTPTIME? or AT+CWJAP?.

Is there a way to setup a delay to the esp32 answers? Or am I doing something wrong so I don't get all the characters from the interrupt?

[ustccw]

i don't think setting a delay is a good solution. Could you please provide the following details to find out what happened.

1. Which AT firmware did you use, and what is the version of the AT firmware?
   -> you can send AT+GMR command to query it.

2. Is your module from Espressif or your own PCB design?
   -> Refer to ESP Modules for more details.

3. How is the module powered?
   -> USB, Battery, etc.

4. Have you enabled UART hardware flow control?
   -> Refer to Hardware Connection for more details.

5. Have you used a logic analyzer to view the data on the lines?
   -> This is the most objective way to know the cause of the issue.

[cjoecker]

Here the answer to your questions:

1. ion:3.1.0.0-dev(s-ef96eaf - ESP32 - Feb 24 2023 09:12:48)
SDK version:v5.0-541-g885e501d99
compile time(3d6e43c):Dec 11 2023 12:00:26
Bin version:2.5.0(WROOM-32)
2. PCB Design
3. USB powered
4. UART hardware flow control is not enabled
5. Yes, I use the CubeIDE logic analyzer and it is working perfectly.
When I run the code normally, is when I have missing letters.

This is my interrupt logic:

void HAL_UARTEx_RxEventCallback(UART_HandleTypeDef *huart, uint16_t Size) {

	/* This Data Receiving from User-Terminal driver */
	if (huart->Instance == USART2) {
		// Save RX Data
		memcpy(main_buffer, uart_dma_rx_buffer, Size);
		size_t eeprom_command_prefix_length = strlen(EEPROM_COMMAND_PREFIX);
        if (strncmp( (char*)main_buffer, EEPROM_COMMAND_PREFIX, eeprom_command_prefix_length) == 0) {
            eeprom_command_to_be_processed_length = Size - eeprom_command_prefix_length;
            memcpy(eeprom_command_to_be_processed, main_buffer + eeprom_command_prefix_length, eeprom_command_to_be_processed_length + 1);
        }else{
            char *s = "Terminal -> Target\n";
            HAL_UART_Transmit(&UART_TERMINAL, (uint8_t*) s, strlen(s), 10);
            HAL_UART_Transmit(&UART_WIFI, uart_dma_rx_buffer, Size, 10);
        }

        // activate RX DAM Interrupt again
        HAL_UARTEx_ReceiveToIdle_DMA(&UART_TERMINAL, uart_dma_rx_buffer, UART_BUFFER_DMA_SIZE);
    }

	/* This is ESP32 Wifi Data Receiving Driver */
	if (huart->Instance == USART1) {
		/* terminate incoming data */
		memset(&esp_dma_rx_buffer[Size], '\0', 1);
		memcpy(at_command_response, esp_dma_rx_buffer, Size);

		if (strstr((char*) esp_dma_rx_buffer, "+MQTTSUBRECV:")) {
			myprintf("Put Fifo\n");
			/* new style with cube talk and nonPeriodicTask handler
			 * save incoming data to fifo, handle later in super loop */
			wifi_module_mssg_t element;
			element.eventType = eUART_WIFI_REQUEST;
			element.len = Size + 1;
			memcpy(element.mssg, esp_dma_rx_buffer, element.len);
			circular_buf_put(&wifi_fifo, &element);
		}

		/* Loop Back - Echo Data To Terminal (UART2) */
		HAL_UART_Transmit(&UART_TERMINAL, esp_dma_rx_buffer, Size, 10);
		/* restart UART RX DMA Interrupt again */
		HAL_UARTEx_ReceiveToIdle_DMA(&UART_WIFI, esp_dma_rx_buffer, ESP_BUFFER_DMA_SIZE);
	}

	/* this is Modbus Client (Master) Receive Driver */
	if (huart->Instance == UART4) {
		//app_HomeCube_UART4_Callback(Size);
	}
}

[ustccw]

@cjoecker Sorry, I am not familiar with your MCU test code. I suggest that as a test, before communicating between the ESP32 module and the MCU, you can try to first communicate between the ESP32 module and a PC to see if it works properly, ensuring that your ESP32 module itself and the AT software are not the issue.

[cjoecker]

@ustccw we tried with a USB-TTL Serial Modul FT232RL FTDI without flow control and it worked correctly.

[ustccw]

Good to know~ it seems that the AT firmware and the ESP32 module itself are fine. The issue lies with the MCU side, so you will need to troubleshoot the relevant problems on the MCU side~

[cjoecker]

I will check my MCU then closely. I will close the issuer for now. Thanks for your support.