Wifi fails just after connected - C++

[KeithInAsia]

I have this peculiar failure of Wifi only after it connects. Seems like somehow the IP address is being stored improperly?

I'm building in VisualGDB w/C++ IDF V4.0. The project is fairly large -- It has successful I2C, BLE, Timer, IO code. Entire project with Wifi/BLE enabled is just over 1M. I have set the factory app space to 2M. I have been working on this project about 8 to 10 months and most things have gone fairly well.

I have done extensive searching but can not seem to find any other similar cases.

Wifi(station mode) proceeds through all phases of connection. I am registering events and everything looks normal until I get the final IP_EVENT_STA_GOT_IP event and a debug message of Wifi: got ip:10.76.167.130.

I'm using the standard code right from the IDF examples library -- and the Wifi STA example when built stand-alone runs correctly on my target hardware.

A Guru Meditation Error: Core 0 panic'ed (StoreProhibited). would indicate that a pointer to a structure is not being initialized and I assume this has something to do with the storage of the IP address that is being returned in that final Wifi event? I'm not an expert in Wifi and I'm struggling to make headway at this point.

I would appreciate any points in the right direction. Thanks.

WifiError.png (133.19 KiB) Viewed 8988 times

[WiFive]

Decode your backtrace

[KeithInAsia]

I don't know how to decode the backtrace. I have done some reading on it but haven't quite figured it out.

[KeithInAsia]

I suspect my problem involves the storage of the IP address. There is a function which I believe is designed to prepare memory for this called -- esp_wifi_set_storage().

That function is not called in my C code example. C versions of projects seem to have different default behaviors for the initialization of memory over C++. Therefore I suspect (and I have not tested this yet) that this call to set up wifi storage is critical for C++ implementations --- and have been excluded from C code because no apparent problems were observed.

[KeithInAsia]

Update to this post... Here is the decode of my backtrace output:

Wifi::event_handler(void*, char const*, int, void*) main/Wifi.cpp:1271 (discriminator 8)

Wifi::eventMarshaller(void*, char const*, int, void*) main/Wifi.cpp:1190

handler_execute at C:/SysGCC/esp32/esp-idf/v4.0/components/esp_event/esp_event.c:145

esp_event_loop_run at C:/SysGCC/esp32/esp-idf/v4.0/components/esp_event/esp_event.c:553 (discriminator 3)

esp_event_loop_run_task at C:/SysGCC/esp32/esp-idf/v4.0/components/esp_event/esp_event.c:115

vPortTaskWrapper at C:/SysGCC/esp32/esp-idf/v4.0/components/freertos/port.c:143

[nvannote]

Update to this post... Here is the decode of my backtrace output:

Wifi::event_handler(void*, char const*, int, void*) main/Wifi.cpp:1271 (discriminator 8)

Wifi::eventMarshaller(void*, char const*, int, void*) main/Wifi.cpp:1190

handler_execute at C:/SysGCC/esp32/esp-idf/v4.0/components/esp_event/esp_event.c:145

esp_event_loop_run at C:/SysGCC/esp32/esp-idf/v4.0/components/esp_event/esp_event.c:553 (discriminator 3)

esp_event_loop_run_task at C:/SysGCC/esp32/esp-idf/v4.0/components/esp_event/esp_event.c:115

vPortTaskWrapper at C:/SysGCC/esp32/esp-idf/v4.0/components/freertos/port.c:143

It would appear the backtrace is pointing at your code.

Code: Select all

Wifi::event_handler(void*, char const*, int, void*) main/Wifi.cpp:1271 (discriminator 8)

I assume (perhaps incorrectly) that `Wifi::eventMarshaller' is just a class static callback that turns around and invokes `event_handler' through the event_handler_arg (usually a `this' pointer). Which is fine as long as the methods are defined correctly; eventMarshaller static; event_handler typically not (but it's suspect as you're forwarding the event_handler_arg through).

You are going to want to look at "main/Wifi.cpp" and what it is doing at line 1271. I do notice that the EXCVADDR is very low/invalid as if it were an offset from a NULL `this' pointer.

I would make sure that the method definitions are sane; and that a valid user context (`this' pointer or something that contains it) is being passed on your esp_event_handler_register(s).


Best Regards

[KeithInAsia]

You are correct about the Wifi::eventMarshaller. That handler is static and then references the object to call its non-static handler.

At line 1271 -- I have the handler for the IP_EVENT IP_EVENT_STA_GOT_IP which makes sense -- I'm crashing on that event.

I'm not intimately familiar with that is being accessed or stored when this event occurs.

The handler is dealing with WIFI_EVENT fine -- but this call-back routes to IP_EVENT (in my following switch statement) and fails. This is the first time we handle an event in the IP_EVENT space. Something in the IP_EVENT space is somehow not being instantiated/initialized prior to the event.

I'm busy now inserting all the equivalent C code line by line into my C++ project to determine where the weakness is. There has to be one of these fundamental functions calls that is not doing what is expected.

The sample code is C is fine --- C++ is behaving just a bit differently.

Final Comment -- here is the code in my IP_EVENT_STA_GOT_IP area:

case IP_EVENT_STA_GOT_IP : { // ESP32 station got IP from connected AP
ESP_LOGI(TAG, " IP_EVENT_STA_GOT_IP") ;
ip_event_got_ip_t* event = (ip_event_got_ip_t*) event_data ;
ESP_LOGI(TAG, "got ip:%s", ip4addr_ntoa(&event->ip_info.ip)) ;
s_retry_num = 0 ;
xEventGroupSetBits(s_wifi_event_group, WIFI_CONNECTED_BIT) ;
break ;
}

These lines are boiler plate from the standard C code example project. I can comment out all the lines inside this handler and nothing changes. I still crash when this event fires. Something behind the scenes is going on.

I appreciate the feedback from you.

[nvannote]

These lines are boiler plate from the standard C code example project. I can comment out all the lines inside this handler and nothing changes. I still crash when this event fires. Something behind the scenes is going on.

Well the code you posted looks sane, nothing sticks out as a potential problem there. I can say that converting the process from C to C++ is probably not the underlying issue (Semantic language differences aside). I have developed a generic library that I use internally to do the same type of C++ wrapping of the IDF components; and it works just fine.

Hard to tell with just the one small code fragment so I can't say if the switch has a fall-through issue or whatnot; but you do mention it crashes with and without.

You mentioned the process is getting large and you seem to have much more going on than just WiFi. Have you increased the stack size of the task?; I would go for a minimum of 4K, if not a bit larger.

It would also be interesting to see what that crash looks like without the handler.

Best Regards

[KeithInAsia]

You know -- I have run into stack size crashes before..... and corrected them... I'm wondering now if it is just not that simple?

I didn't consider stack size up to this point... since this thing ties back to FreeRTOS it might just be a stack size issue.

Keith

[KeithInAsia]

I bumped up the task memory size twice to:

xTaskCreate(runMarshaller, "Wifi::run", 1024 * 8, this, 6, &taskHandleWifi);

No change in condition..... Next, I'll remove the catch on the handler and see what happens.