Getting extra byte 0xFF while configuring UART

[Ritesh]

Hi,

I am getting extra one byte 0xFF while configuring any of UART1 or UART2 using new UART driver provided into ESP32-idf SDK. SO, I have just configured UART2 with following code and checked on ESP32 development kit and found that i am getting extra one byte after configuring it.

Code: Select all

 uart_port_t uart_num = 2;
	
 uart_config_t uart_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,
       .rx_flow_ctrl_thresh = 122,
    };

    //Set UART parameters
    uart_param_config(uart_num, &uart_config);
   
    uart_set_pin(uart_num, 17, 16, UART_PIN_NO_CHANGE, UART_PIN_NO_CHANGE);

So, I have put some debug statements into UART driver and also in my application and found that extra byte is coming while configuring GPIO matrix for TX Pin.

Code: Select all

if(tx_io_num >= 0) {
            PIN_FUNC_SELECT(GPIO_PIN_MUX_REG[tx_io_num], PIN_FUNC_GPIO);
            gpio_set_direction(tx_io_num, GPIO_MODE_OUTPUT);
            gpio_matrix_out(tx_io_num, tx_sig, 0, 0);
        }

So, please let me know if anyone has faced this type issue or solved it or anyone has any clue for that.

[kolban]

If it were me, I'd create a test application that had nothing other than the logic that showed in your post and test that in isolation to everything else to convince myself that there was no other possibility of anything trying to write. When that sample had been created and I had convinced myself that there was no possibility of of a logic error on my part, I'd then post that whole program for examination and recreate. That way, if it does transpire to be a defect, we will be much further along as the boys at Espressif would welcome a recreatable application to validate and test against.

Your fragments of code are useful (necessary) but only show part of the story. I also get nervous when I read "I put debug statements into the UART driver ..." as, again, if it were me, I'd worry that I'd accidentally contaminated the supplied ESP-IDF environment by adding "debug" into the driver code. I'd try and demonstrate the problem using the out-of-the-box-latest ESP-IDF.

I'd also consider attaching a logic analyzer to my output of the UART to see exactly the signal traces that are being generated.

[Ritesh]

If it were me, I'd create a test application that had nothing other than the logic that showed in your post and test that in isolation to everything else to convince myself that there was no other possibility of anything trying to write. When that sample had been created and I had convinced myself that there was no possibility of of a logic error on my part, I'd then post that whole program for examination and recreate. That way, if it does transpire to be a defect, we will be much further along as the boys at Espressif would welcome a recreatable application to validate and test against.

Your fragments of code are useful (necessary) but only show part of the story. I also get nervous when I read "I put debug statements into the UART driver ..." as, again, if it were me, I'd worry that I'd accidentally contaminated the supplied ESP-IDF environment by adding "debug" into the driver code. I'd try and demonstrate the problem using the out-of-the-box-latest ESP-IDF.

I'd also consider attaching a logic analyzer to my output of the UART to see exactly the signal traces that are being generated.

Hi,

Actually, I have validated and tested it with different test-cases on ESP32 Development Kit as well as on our development board and then I have posted question.

So, It seems there is no any UART driver code defect but there may be problem in UART configuration process in which I am getting extra one byte 0xFF while configuring UART driver configurations for specific UART 1 or UART2.

Let me know if you have any idea or clue for this issue or send me example to configure and send data over UART1 or UART2 driver to get any conclusion for this issue.

[WiFive]

Uart 0xff is basically just a start bit meaning the line went low briefly. Maybe this is caused by the order of gpio config operations or whether the pin has a pulldown by default. But usually any robust serial protocol has framing and/or handshake to deal with this.

[Ritesh]

Uart 0xff is basically just a start bit meaning the line went low briefly. Maybe this is caused by the order of gpio config operations or whether the pin has a pulldown by default. But usually any robust serial protocol has framing and/or handshake to deal with this.

Hi,

Yes. It may be possible that GPIO default configuration might be pulled down. So, I will check it with default pull up and will check it again. But, if you are saying that it's indication of start bit then we need to change source code bootloader as well as application of chip or controller which will be connected over UART with ESP32. Because, we are right getting this problem as it is expecting start of frame and getting 0xFF which is not proper frame and will discard that frame.

So, let me check GPIO pull up configurations from software side and if still same issues then need to debug from GPIO Mux Table to solve this issue.

Let me know your opinion or thoughts for this.

[WiFive]

will discard that frame

Should discard byte only, move frame parsing window to next byte. Easy fix.

[Ritesh]

will discard that frame

Should discard byte only, move frame parsing window to next byte. Easy fix.

Yes. But that is not proper solution as we need to find out exact root-cause of this issue. Because, sometimes we need to get bytes in bootloader stage of controller which is connected with ESP32 on UART and it might be possible that we might not have control of bootloader at that time and may cause serious issue if first byte is sent wrong.

That is why I am approaching to find out proper solution for that so that will be helpful for any controller which is connected with ESP32 on any UART1 or UART2.

So, if you have any idea or anyone else has any clue then it will be more helpful to solve this type of issue.

[Ritesh]

Hi,

I have also checked into another UART as well in which i am getting same problem of extra one byte as 0x00 while configuring UART TX pin for that as it is set as Pull Up mode in that controller which is connected over UART.

And also i have checked that I am getting extra byte into default debug UART as well. So, I am getting extra byte in all UARTs (Debug UART, UART1 and UART2) while configuring UART based on UART Pins.

Please let me know if anyone has faced this type of issue and has idea or clue to solve it because issue is coming while configuring UART TX pin using GPIO Mux Table.

[ESP_Angus]

Try calling uart_set_pin() before calling uart_param_config(). This way the UART is only enabled after the signals are correctly routed.

Regarding possible workarounds, calling uart_flush(uart_num) after initialisation may be an acceptable workaround, to flush any noise following UART initialisation.

[Ritesh]

Try calling uart_set_pin() before calling uart_param_config(). This way the UART is only enabled after the signals are correctly routed.

Regarding possible workarounds, calling uart_flush(uart_num) after initialisation may be an acceptable workaround, to flush any noise following UART initialisation.

Hi,

Thanks for reply.

As I have tried first solution like calling usrt_set_pin() before calling uart_param_config() but issue remains same. But When I looked uart_flush API then i found that it should be worked as it will flush whatever content into UART RX and TX Ring buffer if any.

So, uart_flush API is working after configuring UART but before starting any UART communication for that. So, I think that is proper workaround solution for both UART.

Thanks again for providing workaround solution for that.