esp_modem's dce->get_mode() returned wrong mode after dce->pause_netif(true) (IDFGH-16668)

[huming2207]

Answers checklist.

• I have read the documentation for esp-protocols components and the issue is not addressed there.
• I have updated my esp-protocols branch (master or release) to the latest version and checked that the issue is present there.
• I have searched the issue tracker for a similar issue and not found a similar issue.

General issue report

Hi all,

In esp_modem v1.3 and v1.4, it seems like after dce->pause_netif(true) is called, and even if the data mode of the modem is paused, which the modem actually goes into COMMAND mode, the dce->get_mode() still return DATA mode.

Our own network manager library has an implementation below. We do a few retries here because some Quectel modems requires the host to keep quiet for at least 1 second before sending "+++" to exit data mode. Sometimes UART may have some leftover in the Tx buffer to send out, so it may disturb the "+++" request.

Here's our implementation:

esp_err_t cell_modem::pause_data_mode()
{
    for (uint32_t retry = 0; retry < 10; retry += 1) {
        ESP_LOGI(TAG, "pause: pausing netif, attempt %lu", retry);
        auto ret = dce->pause_netif(true);
        if (ret == esp_modem::command_result::TIMEOUT) {
            continue;
        } else if (ret == esp_modem::command_result::FAIL) {
            ESP_LOGE(TAG, "pause: failed");
            return ESP_FAIL;
        } else {
            ESP_LOGI(TAG, "Netif paused");
            return ESP_OK;
        }
    }

    return ESP_ERR_TIMEOUT;
}

esp_err_t cell_modem::resume_data_mode()
{
    if (dce->get_mode() == esp_modem::modem_mode::DATA_MODE) {
        return ESP_OK; // Here we go: it will ALWAYS return ESP_OK here!!!
    }

    for (uint32_t retry = 0; retry < 10; retry += 1) {
        ESP_LOGI(TAG, "resume: resuming netif, attempt %lu", retry);
        auto ret = dce->pause_netif(false);
        if (ret == esp_modem::command_result::TIMEOUT) {
            continue;
        } else if (ret == esp_modem::command_result::FAIL) {
            ESP_LOGE(TAG, "resume: failed");
            return ESP_FAIL;
        } else {
            ESP_LOGI(TAG, "Netif resumed");
            return ESP_OK;
        }
    }

    return ESP_ERR_TIMEOUT;
}

In the code above, the resume_data_mode() will ALWAYS return ESP_OK in the first line if (dce->get_mode() == esp_modem::modem_mode::DATA_MODE) . Because the esp_modem library will not update the state of the mode in DCE_Mode after pause, so it thinks the modem is still in DATA mode if we call dce->get_mode() here. We think this is a bug.

Meanwhile another suggestion is, in the DCE_T::pause_netif(), after netif.pause() is called, I think the host (DTE) UART supposed to be flushed and wait till the Tx to finish. Otherwise we have to do the retry workaround above.

Regards,
Jackson