Mbed-os: ESP8266 CTS/RTS fails in stop_uart_hw_flow_ctrl()

Created on 26 Dec 2018 · 10Comments · Source: ARMmbed/mbed-os

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
70956ee9bb (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

CLOSED mirrored bug

Source

ccli8

Most helpful comment

@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.

ccli8 on 3 Jan 2019

👍2

All 10 comments

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

ciarmcom on 26 Dec 2018

@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.

cmonr on 27 Dec 2018

@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

ccli8 on 28 Dec 2018

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.

cmonr on 28 Dec 2018

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

SeppoTakalo on 31 Dec 2018

Probably fixed in https://github.com/ARMmbed/mbed-os/pull/9173

SeppoTakalo on 31 Dec 2018

Probably fixed in #9173

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

ccli8 on 2 Jan 2019

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...

michalpasztamobica on 2 Jan 2019

@ccli8 Hope the above answers your question. If no update is provided, will consider this resolved once https://github.com/ARMmbed/mbed-os/pull/9215#discussion_r244758256 is merged.

cmonr on 3 Jan 2019

@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.

ccli8 on 3 Jan 2019

👍2

Was this page helpful?

0 / 5 - 0 ratings