possible bug/issue with V4.1 wifi?

User avatar
mzimmers
Posts: 643
Joined: Wed Mar 07, 2018 11:54 pm
Location: USA

possible bug/issue with V4.1 wifi?

Postby mzimmers » Thu Feb 13, 2020 10:31 pm

Hi all -

I've been struggling to get Wifi working in V4.1, using the ESP_NETIF library. I have it working now -- my initialization routine is a composite of the docs, the example in the IDF and the example on github (because none of them seemed 100% correct.) Here's a distillation of my init routine (error checking and initializations have been removed):

Code: Select all

esp_netif_t *m_netif = nullptr;

void Wifi::taskInit()
{
    esp_netif_config_t netifConfig;
    wifi_init_config_t wifiInitConfig;
    static wifi_config_t wifiConfig; // initialization removed for brevity

    ESP_ERROR_CHECK(esp_netif_init());
    ESP_ERROR_CHECK(esp_event_loop_create_default());

    wifiInitConfig = WIFI_INIT_CONFIG_DEFAULT();
    esp_wifi_init(&wifiInitConfig);

    ESP_ERROR_CHECK(esp_event_handler_register(WIFI_EVENT,
                                               ESP_EVENT_ANY_ID,
                                               event_handler,
                                               m_tasks));
    ESP_ERROR_CHECK(esp_event_handler_register(IP_EVENT,
                                               ESP_EVENT_ANY_ID,
                                               event_handler,
                                               m_tasks));

    netifConfig = ESP_NETIF_DEFAULT_WIFI_STA();
    m_netif = esp_netif_new(&netifConfig);
    esp_netif_attach_wifi_station(m_netif);
    esp_wifi_set_default_wifi_sta_handlers();

    ESP_ERROR_CHECK(esp_wifi_set_mode(WIFI_MODE_STA));
    esp_wifi_set_config(ESP_IF_WIFI_STA, &wifiConfig);
    return;
}
Here's the oddity: notice how I have wifi_config_t wifiConfig defined as static? If I don't, I get a stack overflow in the wifi task. I also tried allocating it:
- as a member of the object
- using malloc()
- using new()

All failed identically. Only the static definition worked.

I do have SPIRAM enabled, whihc might be affecting this, though I don't see how. So, my question to the experts is: should I report this as a bug?

Thanks...

ESP_Angus
Posts: 2344
Joined: Sun May 08, 2016 4:11 am

Re: possible bug/issue with V4.1 wifi?

Postby ESP_Angus » Thu Feb 13, 2020 11:21 pm

Hi mzimmers,
mzimmers wrote:
Thu Feb 13, 2020 10:31 pm

Code: Select all

    static wifi_config_t wifiConfig; // initialization removed for brevity
mzimmers wrote:
Thu Feb 13, 2020 10:31 pm
Here's the oddity: notice how I have wifi_config_t wifiConfig defined as static? If I don't, I get a stack overflow in the wifi task. I also tried allocating it:
- as a member of the object
- using malloc()
- using new()

All failed identically. Only the static definition worked.
Can you please give us a simple example of exactly how you're initializing it when it fails? (Looks like the the simplest way would be to remove the "static" causing the wifiConfig structure to be allocated on the stack) Of course you can redact/replace any sensitive fields in the struct (ideally just replace them with placeholder vlaues).

One possibility is that not all members of the struct are being correctly initialized. "static" variables are always initialized to zero but none of the other cases you mentioned will do this.

Some other details which will help analzye this:
  • When you say it "fails", what exactly happens? If there's a crash or an unusual log line which indicates the failure, please post that as well.
  • I don't expect PSRAM is the problem, especially if it fails when you allocate the structure as an automatic variable on the stack (ie the same code posted here but without the "static" keyword). However to rule it out can you please print the address of the structure (when it's about to fail). You can do it like this:

    Code: Select all

    printf("Using wifiConfig structure at %p\n", &wifiConfig);
    esp_wifi_set_config(ESP_IF_WIFI_STA, &wifiConfig);
    
  • Is the wifi library submodule up to date ("git submodule update --init --recursive")
  • Can you please post the exact IDF version you're using? ("git describe --tags"). There's no V4.1 stable release, so any V4.1 version will be a development version.
Thanks,

Angus

User avatar
mzimmers
Posts: 643
Joined: Wed Mar 07, 2018 11:54 pm
Location: USA

Re: possible bug/issue with V4.1 wifi?

Postby mzimmers » Thu Feb 13, 2020 11:32 pm

Hi, Angus -

Initialization is as follows:

Code: Select all

    static wifi_config_t wifiConfig =
        {
            .sta =
            {
                .ssid = {0},        // set in initTask().
                .password = {0},    // set in initTask().
                .scan_method = WIFI_FAST_SCAN,
                .bssid_set = 0,
                .bssid = {0},
                .channel = 0,
                .listen_interval = 0,
                .sort_method = WIFI_CONNECT_AP_BY_SIGNAL,
                .threshold =
                {
                    .rssi = 0,
                    .authmode = WIFI_AUTH_OPEN
                },
                .pmf_cfg =
                {
                    .capable = false,
                    .required = false
                },
            },
        };
    char *p = reinterpret_cast<char *>(wifiConfig.sta.ssid);
    strcpy(p, m_tasks->flash->getSSID().c_str());
    p = reinterpret_cast<char *>(wifiConfig.sta.password);
    strcpy(p, m_tasks->flash->getPSK().c_str());
The values I extract from flash are short strings. I've done a hex dump of the struct after initialization, and verified that the entire struct is 0 except for the ssid and psk fields.

The error message is:
(5342) wifi: new:<1,0>, old:<1,0>, ap:<255,255>, sta:<1,0>, prof:1
I (5342) wifi: state: init -> auth (b0)
***ERROR*** A stack overflow in task wifi has been detected.
abort() was called at PC 0x4008bd6c on core 0

ELF file SHA256: aecc870fe0dfe9816b1067f2a780a6d1433849d42907c8b534afded460ce30d4

Backtrace: 0x4008b97d:0x3ffec600 0x4008bd55:0x3ffec620 0x4008bd6c:0x3ffec640 0x40099498:0x3ffec660 0x400984ac:0x3ffec680 0x40098462:0x3ffec6c0 0x4016aee7:0x00000003 |<-CORRUPTED

Rebooting...
And...

Code: Select all

C:\esp-idf>git describe --tags
v4.1-dev-1957-gaedf89237

C:\esp-idf>
I believe I've kept the submodules up to date.

ESP_Angus
Posts: 2344
Joined: Sun May 08, 2016 4:11 am

Re: possible bug/issue with V4.1 wifi?

Postby ESP_Angus » Fri Feb 14, 2020 2:09 am

Thanks for that extra info.

Are you able to decode the backtrace (it will decode automatically if you use idf_monitor.py, or you can run xtensa-esp32-elf-addr2line otherwise.)

User avatar
mzimmers
Posts: 643
Joined: Wed Mar 07, 2018 11:54 pm
Location: USA

Re: possible bug/issue with V4.1 wifi?

Postby mzimmers » Fri Feb 14, 2020 2:42 pm

Here you go, though I don't know how much it will help:

Code: Select all

$ addr2line -e build/wifibutton.elf
0x4008bd6c
C:/esp-idf/components/esp32/panic.c:125
0x4008b97d
C:/esp-idf/components/esp32/panic.c:157
0x4008bd55
C:/esp-idf/components/esp32/panic.c:174
0x4008bd6c
C:/esp-idf/components/esp32/panic.c:125
0x40099498
C:/esp-idf/components/freertos/tasks.c:2770
0x400984ac
C:/esp-idf/components/freertos/portasm.S:406
0x40098462
C:/esp-idf/components/freertos/portasm.S:206
0x4016aee7
??:?
Thanks for looking.

Who is online

Users browsing this forum: HighVoltage and 117 guests