KeithInAsia wrote: ↑Thu Jun 18, 2020 12:19 pm
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