UART error began after upgrading to 4.2 (IDFGH-4786)

[korstiaanS]

Environment

• Module or chip used: ESP32
• IDF version: v4.2
• Build System: CMake|idf.py
• Compiler version: 2020r3 8.4.0
• Operating System: macOS
• Using an IDE?: No
• Power Supply: external 5V

Problem Description

I have a program that I already use in production for several years now. I recently upgraded to 4.2 and I have big problems. After a long search I found out that a serial port is not sending what it should send.

I use 3 serial ports: 1 for GPS communication, 1 for mobile communication and 1 for connecting a badge reader via RS485.

Since I use v4.2, I see that for example if I send a string AT+CGATT? to the mobile module it sends SOMETIMES strange data. As a result my program won't function and blocks.

For example this code:

ESP_LOGI(TAG, "GSM command:");
ESP_LOG_BUFFER_HEXDUMP(TAG, cmd, length, ESP_LOG_INFO);
// send commmand to module
uart_write_bytes(GSM_UART, cmd, length);

gives an debug output of

I (377147) 364_gsm: GSM command:
I (377150) 364_gsm: 0x3ffeb035   41 54 2b 43 47 41 54 54  3f 0d                    |AT+CGATT?.|

but if I monitor the serial lines it send some rubbish like: TL=0,10

This is a part of a previous command!

This was the initialisation:

uart_config_t uart_gsm_config = {
        .baud_rate = 115200,
        .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(GSM_UART, &uart_gsm_config);
uart_set_pin(GSM_UART, GSM_TXD, GSM_RXD, GSM_RTS, GSM_CTS);
uart_driver_install(GSM_UART, BUF_SIZE * 2, 0, 0, NULL, 0);

I don't use a transmit buffer.

Why is it sending parts of some older data?

I also notice that the problems begin when I start using the third UART (the one with the RS485). If I don't use this UART, this problem does not occur.

Why did it worked fine before?

Can somebody PLEASE help me? It is is urgent.

Korstiaan

[korstiaanS]

Update: Installed latest version (ESP-IDF v4.4-dev-4-g73db14240) and there it works. (for now, after several tests) But it is not advised to use latest version in production. So, what now?

[negativekelvin]

Figure out which commit resolves the issue and request it be applied to other branches https://github.com/espressif/esp-idf/search?q=uart&type=commits

[Alvin1Zhang]

Thanks for reporting and letting us know, and sorry for the inconvenience, we will look into.

[maranhao]

I had this same problem on 4.1, and it looks like resetting through a deep sleep cycle is a workaround, since it gets the UART back to work. Normal firmware reset or flushs do not have any effect on this.

[pchevali]

Hi,

We have noticed the exact same behaviour. Do you have any progresss with this issue ? We tracked the origin of the problem to the call of uart_param_config.

This doesn't work :

uart_config_t uart_gsm_config = {
        .baud_rate = 115200,
        .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(GSM_UART, &uart_gsm_config);
uart_set_pin(GSM_UART, GSM_TXD, GSM_RXD, GSM_RTS, GSM_CTS);
uart_driver_install(GSM_UART, BUF_SIZE * 2, 0, 0, NULL, 0);

This works :

uart_set_baudrate(GSM_UART,115200); 
uart_set_word_length(GSM_UART, UART_DATA_8_BITS);
uart_set_parity(GSM_UART, UART_PARITY_DISABLE);
uart_set_stop_bits(GSM_UART, UART_STOP_BITS_1);
uart_set_pin(GSM_UART, GSM_TXD, GSM_RXD, GSM_RTS, GSM_CTS);
uart_driver_install(GSM_UART, BUF_SIZE * 2, 0, 0, NULL, 0);

I didn't check the commits. But I will have a look in the afternoon.

[LisaTamanti1965]

Hi, I have same problem on 4.2... I tryed, as suggested from @pompompom ....something changed but now ESP32 transmit casual things..

[pchevali]

We are using SDK 4.2 as well, what do you mean by "casual things" ?

[LisaTamanti1965]

On UART output TX pin with an oscilloscope I see bits seems in a not correct baudrate and the UART analysis function of the oscilloscope doesn't succed in ricognize.

[LisaTamanti1965]

This is my original UART configuration (I'm using v4.2-238-g8cd16b60f-dirty)

uart_config_t uart_config = { .baud_rate = 57600, .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_APB,
};

uart_driver_install(UART_BOARD_NUMBER, UART_RX_BOARD_BUFF_DIM, 0, 0, NULL, 0);  
uart_param_config(UART_BOARD_NUMBER, &uart_config);
uart_set_pin(UART_BOARD_NUMBER, UART_BOARD_TX, UART_BOARD_RX, UART_PIN_NO_CHANGE, UART_PIN_NO_CHANGE);

Then every 200msec I write to UART a frame of 20 bytes:

uart_write_bytes(UART_BOARD_NUMBER, (const char*)tx, 20 );

On TX pin with oscilloscope I see that first frame is sent not complete, than second frame starts with bytes not sended of first frame and first bytes of the second frame, third frame starts with other not sended bytes and firstbytes of the third frame...and so on...

I have an other UART busy with connection to BG96 (not correctly functioning too). If I don't use this other UART with BG96 all seems to function correctly.

I tryed to change UART configuration with:

uart_set_baudrate(UART_BOARD_NUMBER, 57600); uart_set_word_length(UART_BOARD_NUMBER, UART_DATA_8_BITS); uart_set_parity(UART_BOARD_NUMBER, UART_PARITY_DISABLE); uart_set_stop_bits(UART_BOARD_NUMBER, UART_STOP_BITS_1); uart_set_pin(UART_BOARD_NUMBER, UART_BOARD_TX, UART_BOARD_RX, UART_PIN_NO_CHANGE, UART_PIN_NO_CHANGE); uart_driver_install(UART_BOARD_NUMBER, UART_RX_BOARD_BUFF_DIM, 0, 0, NULL, 0);

that changed situation but it changed situation in the worse.

Yesterday I was using v4.1-rc-15-gbd72a9ab2-dirty without any problem using 2 UARTs in the same way

[pchevali]

OK, I think we are having the same issue. In my code I have a first call to uart_param_config (earlier in the code). And then the call to indivual setting functions (uart_set_baudrate ...), maybe this is what changes between us. But this is just a workaround, if it does the trick. I think that there is an issue deeper in the sdk

[LisaTamanti1965]

I confirm that with:

uart_config_t uart_config = { .baud_rate = 57600, .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_APB,
};

uart_driver_install(UART_BOARD_NUMBER, UART_RX_BOARD_BUFF_DIM, 0, 0, NULL, 0);  
uart_param_config(UART_BOARD_NUMBER, &uart_config);
uart_set_pin(UART_BOARD_NUMBER, UART_BOARD_TX, UART_BOARD_RX, UART_PIN_NO_CHANGE, UART_PIN_NO_CHANGE);

uart_set_baudrate(UART_BOARD_NUMBER, 57600);
uart_set_word_length(UART_BOARD_NUMBER, UART_DATA_8_BITS);
uart_set_parity(UART_BOARD_NUMBER, UART_PARITY_DISABLE); 
uart_set_stop_bits(UART_BOARD_NUMBER, UART_STOP_BITS_1);

All seems functioning...it's a workaround but is functioning.... Thank you @pompompom !