ESP32 Forum

Hi,

in one of my projects I am experiencing a very strange behaviour when some device connects to the wifi in AP mode. To not attach a whole bunk of code I will try to explain in a simple matter.

I use a global pointer to a structure variable, where during the runtime at need memory is allocated. This variable is then used inside different functions. In one specific function most of the time the program crashes because the data has changed in the phase of connecting to the ESP AP. I use TCP/UDP, but for testing purposes it was disabled o just the wifi initialization is made.

To be sure this really happens a simple task was created which checks when the data has changed. The test scenario was.
1. Allocate memory
2. Call the function, set data
3. Idle
4. Connect to wifi with phone

So the "checking" function should print something just when point 2 reached. If you see the log bellow we see it has changed just before the first wifi system serial output has happen.

pItemList: 3fcd19a4 (Enter point 2)
menuEntry
ClearMenu
pItemList: f2500004 (Changed without control)
I (51134) wifi:new :<1,0>, old:<1,1>, ap:<1,1>, sta:<255,255>, prof:1
I (51135) wifi:station : 0e:78:62:a7:64:fe join, AID=1, bgn, 20
pItemList: 420000a4 (Changed without control)
*NULL
I (51345) wifi:<ba-add>idx:2 (ifx:1, 0e:78:62:a7:64:fe), tid:0, ssn:0, winSize:64
I (51544) esp_netif_lwip: DHCP server assigned IP to a station, IP is: 192.168.1.2
I (51619) wifi:<ba-add>idx:3 (ifx:1, 0e:78:62:a7:64:fe), tid:7, ssn:2, winSize:64
pItemList: 3fcb79b4 (Changed without control)
pItemList: 17 (Changed without control)
I (52457) esp_netif_lwip: DHCP server assigned IP to a station, IP is: 192.168.1.2
pItemList: 2000406 (Changed without control)
pItemList: 17 (Changed without control)
pItemList: 3fcd1a58 (Changed without control)

I was sure it is some of my problems, but the variable cant in my part of code not change. Also other tasks related to wifi are disabled to make sure it would not influence. Has someone any idea?

No way of telling what the problem is without any of your code. The pointer itself may have gotten corrupted, the memory may have been inadvertently free'd somewhere ("use after free"), another pointer may cause erroneous writes to the wrong memory (invalid array index? use after free? invalid cast of a pointer?...), or a stack overflow may have happened w/o being detected.

Edit:

because the data has changed

"The data" = the global pointer?

Yes its a global pointer, which is used for a graphical menu handler. Therefore, it contains multiple information like, number of lines, prev./next menu, label pointers, etc. To attach the whole code wouldn't make sense.

But, this pointer is only changed on a event such as a button press. To make sure my code doesn't cause this problem I have:
1. Disabled all tasks which are related to wifi and performed only the AP initialization like this: 2. I entered the specific menu where the crash occurs and made sure no button will be pressed durring wifi connect

So the program crashed ONLY if connect to wifi and also only then the memory is overwriten (except of course if a button would be pressed). If the the phone will not connect everything works as expected.

daniSi wrote: ↑

Wed Jul 26, 2023 2:05 pm

Yes its a global pointer, which is used for a graphical menu handler. Therefore, it contains multiple information like, number of lines, prev./next menu, label pointers, etc. To attach the whole code wouldn't make sense.

But, this pointer is only changed on a event such as a button press. To make sure my code doesn't cause this problem I have:
1. Disabled all tasks which are related to wifi and performed only the AP initialization like this:

Code: Select all

	ESP_ERROR_CHECK(esp_netif_init());
	wifi_event_group = xEventGroupCreate();
	ESP_ERROR_CHECK(esp_event_loop_create_default());
	ESP_ERROR_CHECK(esp_event_handler_instance_register(WIFI_EVENT, ESP_EVENT_ANY_ID, &wifi_event_handler, NULL, NULL));
	ESP_ERROR_CHECK(esp_event_handler_register(IP_EVENT, IP_EVENT_STA_GOT_IP, &wifi_event_handler, NULL));
	
		// Copy saved AP SSID and pass. setting to esp wifi structure
	strcpy((char*)wifi_config_ap.ap.ssid, settings.wifi.SSID.value);
	memset(wifi_config_ap.ap.password, 0, 64);
	strcpy((char*)wifi_config_ap.ap.password, settings.wifi.password.value);
	wifi_config_ap.ap.ssid_len = strlen((char*)wifi_config_ap.ap.ssid);
	wifi_config_ap.ap.max_connection = 1;
	wifi_config_ap.ap.channel = 0;
	if (strlen((char*)wifi_config_ap.ap.password) == 0) {
		wifi_config_ap.ap.authmode = WIFI_AUTH_OPEN;
	} else {
		wifi_config_ap.ap.authmode = WIFI_AUTH_WPA_WPA2_PSK;
	}
	if (strlen((char*)wifi_config_ap.ap.ssid) == 0) {
		strcpy((char*)wifi_config_ap.ap.ssid, "pico");
	}
	esp_wifi_set_mode(WIFI_MODE_AP);
	esp_wifi_set_config(ESP_IF_WIFI_AP, &wifi_config_ap);

2. I entered the specific menu where the crash occurs and made sure no button will be pressed durring wifi connect

So the program crashed ONLY if connect to wifi and also only then the memory is overwriten (except of course if a button would be pressed). If the the phone will not connect everything works as expected.

you need to close in braces like (char*)(wifi_config_ap.ap.ssid), same with (char*)(wifi_config_ap.ap.password), etc

you need to close in braces like (char*)(wifi_config_ap.ap.ssid), same with (char*)(wifi_config_ap.ap.password), etc

I wouldn't agree with you that this is really needed in C.

daniSi wrote: ↑

Thu Jul 27, 2023 6:14 am

I wouldn't agree with you that this is really needed in C.

The C specification doesn't agree either.

daniSi wrote: ↑

Wed Jul 26, 2023 2:05 pm

Yes its a global pointer,

Ok, so it's the pointer which is overwritten, not the data it points to.

To attach the whole code wouldn't make sense.

Maybe not. But

this pointer is only changed on a event such as a button press.

indicates that it is inadvertently/erroneously overwritten by some other code (see my first answer) possibly completely unrelated to where you intentionally operate on the pointer variable. So, not seeing the code which is actually at fault, there's not much help we can provide beyond recommending to go looking for any invalid memory accesses or pointer handling across your code base.

One option to trace this down: can you attach a debugger via (USB-serial-)JTAG and set a watchpoint on that pointer?

ESP_Sprite wrote: ↑

Sun Jul 30, 2023 9:51 am

One option to trace this down: can you attach a debugger via (USB-serial-)JTAG and set a watchpoint on that pointer?

Good idea. I have tried it out. The program already crashes before even the watchpoint can be cached. The result is as followed:


Break at address "0x400570ee" with no debug information available, or outside of program code.

In the terminal the last line which was printet is:
I (145012) wifi:new :<1,0>, old:<1,1>, ap:<1,1>, sta:<255,255>, prof:1