Wifi fails just after connected - C++

[nvannote]

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

Well, difficult to debug this one over a forum, not looking at the big picture. So I am running short on ideas. Which probably means it's something silly I am overlooking.

The fact that your IP address logging statement makes it to the console kinda rules out anything (code wise) before that.

I would double check `s_wifi_event_group' is what it's supposed to be, and that it's initialized correctly. I looked at xEventGroupSetBits and it's a little light on how it verifies the event group handle. A bad value could get past the configASSERT statements pretty easy. Although, I would think that would have shown in the backtrace.

Short of that; I might enable the stack smashing protection (CONFIG_COMPILER_STACK_CHECK_MODE) flag to see if it catches anything.

Best Regards

[KeithInAsia]

I notice something.... I was mistaken about how it crashes.

Inside that event handler -- these follow 2 lines always work:

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));

But the next 2 lines always crash the process

s_retry_num = 0;
xEventGroupSetBits(s_wifi_event_group, WIFI_CONNECTED_BIT);


The variables s_retry_num and s_wifi_event_group are initialied/set in another task. I'm not being careful to employ any cross-task techniques when I work with those variables in the event-handlers.

And I'm a bit new to freeRTOS -- but I'm assuming that these variables reside in another location within another task space? And when the event handler tried to access this in the wrong task we have this uninitialized pointer? Does that make any sense?

I would either need to get those variables into the right task space or use safer method to access them across task spaces?

[nvannote]

I notice something.... I was mistaken about how it crashes.

Inside that event handler -- these follow 2 lines always work:

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));

But the next 2 lines always crash the process

s_retry_num = 0;
xEventGroupSetBits(s_wifi_event_group, WIFI_CONNECTED_BIT);


The variables s_retry_num and s_wifi_event_group are initialied/set in another task. I'm not being careful to employ any cross-task techniques when I work with those variables in the event-handlers.

And I'm a bit new to freeRTOS -- but I'm assuming that these variables reside in another location within another task space? And when the event handler tried to access this in the wrong task we have this uninitialized pointer? Does that make any sense?

I would either need to get those variables into the right task space or use safer method to access them across task spaces?

I don't think that's a problem, as long as you can "guarantee" that the event group is initialized before your wifi component attempts to access it. The event group is a synchronization primitive after all. I would make the retry count an instance variable though.

What I had done; In a library implementation file; I have an internal global event group that is only exposed (via. extern) to the library components that need it via. a private header file. The single event group is shared among different components (wifi, sntp etc.) each having their own `bits' defined in the same private header to ease maintenance.

That private event group (and a few other internals) are initialized “early” with a function attributed with `__attribute__((constructor))'.

In the above configuration, I have not seen any issues. As a sanity check; I implemented a test “system monitor” task for an existing project that monitors these components; So at that point there are three tasks involved; No problem.

Best Regards

[nvannote]

That private event group (and a few other internals) are initialized “early” with a function attributed with `__attribute__((constructor))'.

Self imposed disclaimer for those that may read that.

Functions marked as `__attribute__((constructor))' are called before the task that calls app_main is even created (cpu_start.c); and while freeRTOS itself is pretty much "ready to go", there is also additional internal initialization going on; I would advise against getting creative in such functions; keep it very simple.

Regards

[KeithInAsia]

I first confirmed that there is nothing wrong with the basic code. I used my procedures in a small C++ test project. Its fine.


I then ported over the project to VS Code/PIO (away from VS2019/VisualGDB).


I had to remove the BLE test section of the project due to missing dependencies (haven't figured out yet what the hold up is with this PIO build)

I ran the project and it is fine. It's working. Wifi connected as expected and holds fine.

I can not detect any failures at this point. However -- I did remove that BLE section which made my partition table acceptable at the standard default 1M.

So, I'm going back now to add the custom partition table and increase my program size back to 2M -- and see if that has any negative effects.

[KeithInAsia]

NO WAIT.... rats.... I forgot that I had commented out several lines where the failure occurred before.

When I return those lines to the project (in Wifi.cpp) ...


this->s_retry_num = 0;
xEventGroupSetBits(s_wifi_event_group, WIFI_CONNECTED_BIT);


-- I'm back to my trouble...

I'm back to thinking I have a task organization issue....

[KeithInAsia]

Those offending lines ARE in my test project and run fine. So, I have to be doing something wrong in the tasks... or FreeRTOS area.

K.

[KeithInAsia]

The tasks are ok...

My problem is that I'm accessing my instance variables incorrectly.

When I move the offending variables local to the module (cpp file) then I'm not crashing.

You would think that once I marshal over to my instance event task routine -- that I could use the this->variable -- but it doesn't work.


I do pass over from the eventMarshaller the "void *arg" (which is the instance pointer) -- but when I create another variable to get a handle on it -- (auto obj = (Wifi *)arg;) and then use it obj->variable I'm still crashing.

[KeithInAsia]

[FOUND THE ANSWER]

When you connect an Event Hander -- you use the following as a boilerplate:

esp_event_handler_register(EVENT, ESP_EVENT_ID, &handler, null);

The problem is that you must pass in the instance variable -- 'this':

esp_event_handler_register(WIFI_EVENT, ESP_EVENT_ANY_ID, &eventMarshaller, this);

I wasn't doing that -- so I was not able to get instance variable correctly.

I did it right when I wrote up my task handler (passing in 'this') -- I just wasn't paying close enough attention when I wrote the event handlers (which I have not done before for an instance).

[nvannote]

[FOUND THE ANSWER]

Right, As I said.

https://esp32.com/viewtopic.php?f=13&t=15950#p61364

Glad you figured it out.

Best Regards