UART software flow control

[zliudr]

From ESP32 Technical Reference Manual V4.1, page 346, software flow control:
"When UART_SEND_XOFF is set, the transmitter will insert a UART_XOFF_CHAR and send it after the current data transmission is completed." So what is the data they refer to, the entire TX FIFO buffer, just the current byte that's being serially sent out?

Also if I enable software flow control on UART_NUM_0 and use ctrl-s to send xoff from my PC terminal, it stops ESP32 from sending but reboots after a few seconds if I don't do ctrl-q to send xon. There seems to be no error message what's going on. In my app I'm printing analog values:

Raw: 4095 Voltage: 3134mV
Raw: 4095 Voltage: 3134mV
Raw: 4095 Voltage: 3134mV
Raw: 4095 Voltage: 3134mV
Raw: 4095 Voltage: 3134mV
Raw: 4095 Voltage: 3134mV
ets Jun 8 2016 00:22:57

rst:0x8 (TG1WDT_SYS_RESET),boot:0x3f (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0018,len:4
load:0x3fff001c,len:6432
ho 0 tail 12 room 4
load:0x40078000,len:11624
ho 0 tail 12 room 4
load:0x40080400,len:6700
entry 0x40080768
W (194) boot: PRO CPU has been reset by WDT.
W (194) boot: WDT reset info: PRO CPU PC=0x400861fa
W (194) boot: WDT reset info: APP CPU PC=0x4008670f

I used printf() but also tried ESP_LOGI(). Did UART_NUM_0's software buffer run out? Maybe not? The reason for reboot was WDT reset on PRO CPU. Why is WDT triggered? Is PRO CPU hung up in a uart_write_bytes() call while uart controller is waiting for xon? Maybe I should test this with UART1 running on APP CPU without WDT reset?

[ESP_Sprite]

Pretty sure that indeed, the internal buffers are entirely filled up and the watchdog timer resets the chip as to it, the CPU is 'stuck' in a routine somewhere. Because the UART still is waiting for the XON at that time, printing the core dump also gets held up, so you don't see that. In general, the system is intended for small periods of time between XOFF/XON, not multiple seconds.

[zliudr]

ESP_Sprite,
Yes, you're right! XON/XOFF should be just short periods of time but what if this feature is turned on and the other side misbehaved, sending XOFF and didn't send XON? I guess if it were uart_1 or 2 that I install driver on APP CPU, then WDT will just fire up warning messages until XON is received again, with all other tasks on pause?

Also the ESP-IDF call: uart_set_sw_flow_ctrl(uart_port_t uart_num, bool enable, uint8_t rx_thresh_xon, uint8_t rx_thresh_xoff)
Are the thresholds compared with the typical 128 byte long uart buffer size?

Thanks.

https://docs.espressif.com/projects/esp ... wcontrol_t

[zliudr]

OK, I printed to UART_NUM_1 with software flow control enabled and monitored both this port (over a USB adapter) and the console port. Pausing this stream with XOFF for some extended amount of time cause neither WDT complaint message (say when I loop without a delay()) nor a reboot. APP CPU is happily stuck somewhere although I don't have another task to confirm APP CPU is still running tasks.

[zliudr]

OK, I added a task to print 1 second ticks. It seems that when I XOFF'd UART_NUM_1, the tisk_task() still runs so that is very good news!
Also to raise another question and answer it myself: how does uart hardware handle XOFF from PC side? I think it stops transmission immediately, even if it's in the middle of printing something. I randomly sent XOFF and some of the printed messages got printed only partially and then resumed printing after I sent XON. This is a good indication that the uart hardware immediately stops transmission, not when ALL data are sent. It's more responsive this way, more than I can implement on application-software-level.

Really hope someone could answer my other thread about hardware flow control. Meanwhile I'll do more tests.