ESP8266 CTS/RTS fails in stop_uart_hw_flow_ctrl()

[ccli8]

Description

I am evaluating ESP8266 CTS/RST on Nuvoton target, for example on NUMAKER_PFM_M487. For this test, I have UART CTS/RTS/RST connected besides UART Rx/Tx, For enabling CTS/RTS and reset functions, I pass these pins to ESP8266 driver as below:

static ESP8266Interface esp(D1, D0, false, A2, A3, D2);

Without any change to ESP8266 driver, I am very easy to meet _esp.stop_uart_hw_flow_ctrl() failure:

mbed-os/components/wifi\esp8266-driver/ESP8266Interface.cpp (no change):

nsapi_error_t ESP8266Interface::_init(void)
{
    if (!_initialized) {
        _hw_reset();
        if (!_esp.at_available()) {
            return NSAPI_ERROR_DEVICE_ERROR;
        }
        if (!_esp.stop_uart_hw_flow_ctrl()) {
            return NSAPI_ERROR_DEVICE_ERROR;
        }
        if (!_esp.reset()) {
            return NSAPI_ERROR_DEVICE_ERROR;
        }

AT log of _esp.stop_uart_hw_flow_ctrl() failure:

Start WiFi test
Start Connection ...

Using WiFi

Connecting to WiFi..
AT> AT
AT? OK
%n
AT< rlAT< ▒
▒AT< ll`b▒▒▒
▒▒r▒▒AT< ready
AT! WIFI
AT? %*12[^"]
%n
AT= CONNECTED

AT? OK
%n
AT(Timeout)
AT> AT
AT? OK
%n
AT< AT
AT= OK


AT> AT+UART_CUR=115200,8,1,0,0
AT? OK
%n
AT? OK
AT+UART_CUR=115200,8
AT< ,1,0,0
AT< OK
AT< AT+OK
AT? %n
AT(Timeout)

If I re-try _esp.stop_uart_hw_flow_ctrl() like below, it can work. And the ESP8266 CTS/RTS function is workable after this modification.

mbed-os/components/wifi\esp8266-driver/ESP8266Interface.cpp (retry _esp.stop_uart_hw_flow_ctrl()):

nsapi_error_t ESP8266Interface::_init(void)
{
    if (!_initialized) {
        _hw_reset();
        if (!_esp.at_available()) {
            return NSAPI_ERROR_DEVICE_ERROR;
        }
        if (!_esp.stop_uart_hw_flow_ctrl()) {
            
            if (!_esp.stop_uart_hw_flow_ctrl()) {
                return NSAPI_ERROR_DEVICE_ERROR;
            }
            
        }
        if (!_esp.reset()) {
            return NSAPI_ERROR_DEVICE_ERROR;
        }

AT log of retrying _esp.stop_uart_hw_flow_ctrl() failure:

Start WiFi test
Start Connection ...

Using WiFi

Connecting to WiFi..
AT> AT
AT? OK
%n
AT< rlAT< ▒
▒AT< ll`b▒▒▒
▒▒r▒▒AT< ready
AT! WIFI
AT? %*12[^"]
%n
AT= CONNECTED

AT? OK
%n
AT(Timeout)
AT> AT
AT? OK
%n
AT< AT
AT= OK


AT> AT+UART_CUR=115200,8,1,0,0
AT? OK
%n
AT? OK
AT+UART_CUR=115200,
AT< 8,1,0,0
AT< OK
AT< GOT IP
AT(Timeout)
AT? %n
AT(Timeout)
AT> AT+UART_CUR=115200,8,1,0,0
AT? OK
%n
AT< AT+UART_CUR=115200,8,1,0,0
AT= OK


AT> AT+RST
AT? OK
%n
AT< AT+RST
AT= OK

mbed-os SHA
70956ee (origin/master, origin/HEAD, master) Merge pull request #8955 from ARMmbed/dreemkiller_LPC54608_fix

ESP8266 AT version
1.6.2

ESP8266 SDK version
2.2.1

Related issue

#9088

Issue request type

[ ] Question
[ ] Enhancement
[x] Bug

[ciarmcom]

Internal Jira reference: https://jira.arm.com/browse/MBOCUSTRIA-365

[cmonr]

@ccli8 Updated your comment to ass add color highlighting to c blocks. Makes it a bit easier to read. (Not sure where the references came from in the edit tho...)

Also, would you be willing to try out v1.7.0 of the ESP FW and see if the issue still persists?

@ARMmbed/mbed-os-connectivity Fyi.

[ccli8]

@cmonr I try 1.7.0 AT+CTS/RTS and the issue disappears. So upgrade to v1.7.0 AT is must?

AT log of 1.7.0 AT:

Start WiFi test
Start Connection ...

Using WiFi

Connecting to WiFi..
AT> AT
AT? OK
%n
AT<
AT= OK

AT> AT+UART_CUR=115200,8,1,0,0
AT? OK
%n
AT= OK

AT> AT+RST
AT? OK
%n
AT= OK

[cmonr]

The connectivity team would be better able to answer, but we noticed a bunch of flow control issues dueing the 5.11.0 release that were vastly improved by updating the ESP32s to their latest firmware.

[SeppoTakalo]

@VeijoPesonen @michalpasztamobica Is this the same issue we were seeing with client pause-resume functionality?

[SeppoTakalo]

Probably fixed in #9173

[ccli8]

Probably fixed in #9173

@SeppoTakalo Yes. This issue is also what #9173 is addressing.

[michalpasztamobica]

Surely, #9173 will fix this, as it completely removes the stop of hw uart flow control.
The symptoms are also same (commands timing out when we try to reconnect).
The question is: should we remove the stopping or should we call it twice in case it fails? I would go for removing, as it seems generally harmless (as discussed in #9173) and simplifies the code.

Perhaps some future version of AT firmware or ESP chip will let us safely start and stop UART hw control...

[cmonr]

@ccli8 Hope the above answers your question. If no update is provided, will consider this resolved once #9215 (comment) is merged.

[ccli8]

@cmonr @michalpasztamobica Removing stop_uart_hw_flow_ctrl() in _init() or calling it twice are both OK per my test on 1.6.2 AT firmware.