How can I reset Serial2 / UART2?

[jestebanes]

Hardware:

Board: Own design based on ESP-WROOM-32
Core Installation/update date: 23/sept/2017
IDE name: Arduino IDE
SDK version: v3.0-dev-745-gc4e65d6a
Flash Frequency: 80Mhz
Upload Speed: 512000

Description:

I am using OTA to upgrade my firmware but after a software update Serial2 doesn't work properly
Apparently, if I make a hardware reset, the serial port works fine but if ESP.restart() is used the serial port doesn't work.

Doing a little investigation, ESP.restart call to esp_restart(); defined in system.h and I found, the library header. Then the problem is clear UART1 and UART2 weren't reset.

how can I reset those UARTs?

/**

• @brief Restart PRO and APP CPUs.
• This function can be called both from PRO and APP CPUs.
• After successful restart, CPU reset reason will be SW_CPU_RESET.
• Peripherals (except for WiFi, BT, UART0, SPI1, and legacy timers) are not reset.
• This function does not return.
  */
  void esp_restart(void) attribute ((noreturn));

Best wishes

[me-no-dev]

What do you see as errors? Old data? Generally SerialX.begin should reinit the serials.

[kurtow]

Board: ESPRESSIF ESP32-DEVKITC based on ESP-WROOM-32
Core Installation/update date: 23/sept/2017
IDE name: Arduino IDE

Hello,
I have the same problem.
After a hardware reset, the Serial2 runs with a probability of about 50%
(sometimes I had to reset three or four times before it starts)

After restarting from deepsleep Serial2 runs with a probability of 20%.
(In most cases its hanging after restart)
I mean (but I am not sure), that this problem did not occur
at my last arduino-core download of 21.08.

edited by kurtow:
here is new issue by emilekm2142
Hardware serial 2 does not work #665

kindly regards

[jestebanes]

Hello @me-no-dev , I see a lot of crap

This is a communication after one hard reset or powering up the device, using UART2 connected to pins 16 & 17 at 19200 bauds, the first line is a question sent by ESP32 to the serial client and the second line is the response of the client on the serial bus, the numbers before : are the timeline. The data is obtained with an external hardware that sniffs the serial bus. Every line ends with an ACK, client sent ACK to ESP32 and ESP32 send ACK to the client

P300138824:031D58C0156F5C 1A
P300138833:03C059C015C9E9 CA

P300138839:0300FF00C0F8FD 0A
P300138849:06C0FE001000BDA46159 CA

P300141726:031D58C0002DC8 1A
P300141733:03C059C0008B7D CA

P300142151:021D5C05F72D 1A
P300142159:05C05D05303332CCE8 CA

P300142166:026D5C052F25 6A
P300142201:05C05D05323531384D CA

After the OTA update the first command change to this sequence, you can see the same bytes but they are not sent in the correct order, is like they are rotated in the buffer. In these sequences, there is no ACK because they are wrong, ESP tries to send several times without success.

P300121672:021D58031D5800
P300121700:156F5C031D58C0
P300121727:156F5C031D58C0
P300121748:156F5C031D58C015
P300122749:6F5C031D58C0156F
P300123750:5C031D58C0156F5C
P300124753:031D58C0156F5C00
P300125759:1D58C0156F5C031D
P300126762:58C0156F5C031D58
P300127765:C0156F5C0300FF00

But the bytes read by ESP32 in serial port are wrong too if I read the last sequence with ESP32, I receive

7780: 50006100E58A1A
7801: 041150006100E5
7822: 8A1A0400500011
7844: 0043021D58C292421458C2
7869: C29242021D58C2
7897: 5000110043D81A
7922: 42CA021D58C292
7944: 041150006100E5
7971: 8A1A42CA021D58
7998: C29242021D58C2

I think there must be some kind of bits in the UART register that becomes 0 after a hard reset, but serial.begin ignores it and cause this issue.

Best regards

[me-no-dev]

Please pull the latest changes and report :) Thanks!

[jestebanes]

Hello @me-no-dev, this issue was not solved with the last commit

Best regards

[jestebanes]

Is the same thing, before the OTA update, with serial 2, the data sent is:

P300235436: 021D58C29242 1A

After the OTA update, the data is rotated in the serial 2

P300426334: 9242 CA 021D58C2

The CA is the CRC failure, same code different behavior. After a hard reset, the system goes to their normal behavior.
¿is this a problem to report to esp-idf?

Bye

[me-no-dev]

looks like data comes out of order?

[jestebanes]

The command that sent the data is Serial2.printf and I read with an external Arduino.
Is like the begin of the fifo was shifted two or three bytes and the serial2.printf command writes the bytes in a wrong place or the serial port hardware takes it from a shifted place.

[me-no-dev]

that is not really possible ;) Serial.print sends the bytes one by one in a blocking manner

[jestebanes]

Upps, not print is write
if(Serial2.write(send, tamPaq)!=tamPaq)

that calls to hardwareSerial.cpp

size_t HardwareSerial::write(const uint8_t *buffer, size_t size)
{
uartWriteBuf(_uart, buffer, size);
return size;
}

that calls to esp32-hal-uart.c

void uartWriteBuf(uart_t* uart, const uint8_t * data, size_t len)
{
if(uart == NULL) {
return;
}
UART_MUTEX_LOCK();
while(len) {
while(len && uart->dev->status.txfifo_cnt < 0x7F) {
uart->dev->fifo.rw_byte = *data++;
len--;
}
}
UART_MUTEX_UNLOCK();
}

This function isn't waiting to transmit the byte, while still room in the fifo it is pushing every byte.

[lonerzzz]

Not sure if it applies equally here but I found that over a reboot, the I2C FSM (state machine) was left in a funny state. I just submitted a pull request to add the reset function for I2C. It does so by calling the following:

periph_module_disable( PERIPH_I2C0_MODULE );
delay( 20 ); // Seems long but delay was chosen to ensure system teardown and setup without core generation
periph_module_enable( PERIPH_I2C0_MODULE );

For the UART, the same type of operation would be:

periph_module_disable( PERIPH_UART0_MODULE );
delay( 20 );
periph_module_enable( PERIPH_UART0_MODULE );

or using PERIPH_UART1_MODULE or PERIPH_UART2_MODULE depending on which UART you are using.

I had to add code to the I2C HAL layer to do so, had to include the following:

#include "driver/periph_ctrl.h"

and had to call the I2C initialization code once again after doing so. Doing something similar may be worth trying in your case.

[jestebanes]

Thanks @lonerzzz, I try but this does not work for me, There is some change in the behavior in UART2 but still desynchronized
Best regards

bool Dbus2::init(Debug *pdebug){
dbg = pdebug;
speed = 19200;

periph_module_disable(PERIPH_UART2_MODULE);
delay(20);
periph_module_enable(PERIPH_UART2_MODULE);

Serial2.begin(19200, SERIAL_8N1);

return true;
}

[lonerzzz]

One other thing worth looking at is in uartBegin in the file esp32-hal-uart.c. The code there is such that if the queue has been created, it won't be created again so if you were out of sync and the internal queue is unchanged, then you are likely facing some unexpected data right from the start.

    if(queueLen && uart->queue == NULL) {
        uart->queue = xQueueCreate(queueLen, sizeof(uint8_t)); //initialize the queue
        if(uart->queue == NULL) {
            return NULL;
        }
    }

It would be worth ensuring that the queue is empty as a part of resetting.

[me-no-dev]

OK I think it's time you show some code :) both on ESP and AVR ;)

[jestebanes]

I'm out for a while.
I've tried to read the port status in both conditions, with a hardware reset and a software reset by an OTA update, but I can't find some significative differences in the status of the UART registers. This is why module_disable and enable doesn't work.
I use this piece of software into the esp32-hal-uart.c

void uartConfiguration(uint8_t uart_nr, char resul, int size)
{
if(uart_nr != 2) {
return; //Not return NULL
}
uart_t uart = &_uart_bus_array[uart_nr];
UART_MUTEX_LOCK();
snprintf(resul, size, "\nUart2 register values:\nUART_CONF0 %08X\nUART_CONF1 %08X\nUART_CLKDIV %08X\nUART_FLOW_CONF %08X\nUART_SWFC %08X\nUART_SLEEP_CONF %08X\nUART_IDLE_CONF %08X\nUART_RS485_CONF %08X\nUART_STATUS %08X\nUART_AUTOBAUD %08X\nUART_FIFO_REG %08X\nUART_MEM_CONF %08X\nUART_MEM_CNT %08X\nAT_CMD_PRECNT %08X\nAT_CMD_POSTCNT %08X\nAT_CMD_GAPOUT %08X\nAT_CMD_CHAR %08X\nINT_RAW %08X\nINT_ST %08X\nINT_ENA %08X\nINT_CLR %08X\n",
ESP_REG(UART_CONF0_REG(uart_nr)), ESP_REG(UART_CONF1_REG(uart_nr)), ESP_REG(UART_CLKDIV_REG(uart_nr)),
ESP_REG(UART_FLOW_CONF_REG(uart_nr)), ESP_REG(UART_SWFC_CONF_REG(uart_nr)), ESP_REG(UART_SLEEP_CONF_REG(uart_nr)),
ESP_REG(UART_IDLE_CONF_REG(uart_nr)), ESP_REG(UART_RS485_CONF_REG(uart_nr)),
ESP_REG(UART_STATUS_REG(uart_nr)), ESP_REG(UART_AUTOBAUD_REG(uart_nr)), ESP_REG(UART_FIFO_REG(uart_nr)),
ESP_REG(UART_MEM_CONF_REG(uart_nr)), ESP_REG(UART_MEM_CNT_STATUS_REG(uart_nr)), ESP_REG(UART_AT_CMD_PRECNT_REG(uart_nr)),
ESP_REG(UART_AT_CMD_POSTCNT_REG(uart_nr)), ESP_REG(UART_AT_CMD_GAPTOUT_REG(uart_nr)), ESP_REG(UART_AT_CMD_CHAR_REG(uart_nr)),
ESP_REG(UART_INT_RAW_REG(uart_nr)), ESP_REG(UART_INT_ST_REG(uart_nr)), ESP_REG(UART_INT_ENA_REG(uart_nr)),
ESP_REG(UART_INT_CLR_REG(uart_nr)));
UART_MUTEX_UNLOCK();
}

Following the @lonerzzz suggestion I change the uartBegin to delete the oldest structures and I insert this code in uartBegin with no results at all

#if !CONFIG_DISABLE_HAL_LOCKS
if(uart->lock != NULL) {
vSemaphoreDelete(uart->lock);
uart->lock=NULL;
}
if(uart->lock == NULL) {
uart->lock = xSemaphoreCreateMutex();
if(uart->lock == NULL) {
return NULL;
}
}
#endif
if(uart->queue != NULL){
vQueueDelete(uart->queue);
uart->queue = NULL;
}
if(queueLen && uart->queue == NULL) {
uart->queue = xQueueCreate(queueLen, sizeof(uint8_t)); //initialize the queue
if(uart->queue == NULL) {
return NULL;
}
}else{
xQueueReset(uart->queue);
}