MisterScience5
commented
1 year ago I've been experimenting a lot with this, it seems to either be gone or less frequent after i did the following two changes:
- Disabled wifi/bluetooth SW controlled coexistence
- Changed the compiler optimization to performance instead of size
Sadly, I can't confirm which of these made a difference as I did them close in time and didn't register any errors meanwhile. I'll be able to confirm whether the error is fully gone or only less frequent in a few days as I have a large network of mesh nodes running and logging data.
I also made a better disable function to help with these sorts of deadlocks, using a separate high priority task with a watchdog.
void esp_mesh_disable_task(void *arg)
{
esp_err_t err = ESP_OK;
esp_task_wdt_add(NULL);
esp_mesh_disabling = true;
err = esp_mesh_set_self_organized(false, false);
ESP_LOGI(MESH_TAG, "Disabling self organized returned 0x%x (%s)", err, esp_err_to_name(err));
sleep(20);
err = esp_mesh_disconnect();
ESP_LOGI(MESH_TAG, "Disconnecting from parent returned 0x%x (%s)", err, esp_err_to_name(err));
sleep(20);
err = esp_wifi_scan_stop();
ESP_LOGI(MESH_TAG, "Stopping scan returned 0x%x (%s)", err, esp_err_to_name(err));
sleep(20);
err = esp_mesh_flush_scan_result();
ESP_LOGI(MESH_TAG, "Flushing scan results returned 0x%x (%s)", err, esp_err_to_name(err));
sleep(20);
err = esp_mesh_flush_upstream_packets();
ESP_LOGI(MESH_TAG, "Flushing upstream packets returned 0x%x (%s)", err, esp_err_to_name(err));
sleep(20);
esp_log_level_set("mesh", ESP_LOG_ERROR);
err = esp_mesh_stop();
ESP_LOGI(MESH_TAG, "Stopping mesh returned 0x%x (%s)", err, esp_err_to_name(err));
sleep(100);
err = esp_mesh_deinit();
ESP_LOGI(MESH_TAG, "Deiniting mesh returned 0x%x (%s)", err, esp_err_to_name(err));
sleep(100);
esp_log_level_set("mesh", ESP_LOG_WARN);
ESP_LOGW(MESH_TAG, "ESP mesh disabled!");
err = esp_wifi_stop();
ESP_LOGI(MESH_TAG, "Stopping wifi returned 0x%x (%s)", err, esp_err_to_name(err));
sleep(100);
esp_mesh_disabling = false;
esp_task_wdt_delete(NULL);
vTaskDelete(NULL);
}
esp_err_t esp_mesh_disable()
{
uint32_t timeout = 0;
mesh_tx_pending_t tx_pending = { 0, };
esp_err_t err = ESP_OK;
if(esp_mesh_active)
{
xTaskCreate(&esp_mesh_disable_task, "mesh_dis", 4096, NULL, 17, NULL);
while(esp_mesh_disabling && timeout < 20000)
{
sleep(100);
}
if(!esp_mesh_active)
{
return ESP_OK;
}
return ESP_FAIL;
} else {
ESP_LOGE(MESH_TAG, "Mesh network already disabled!");
return ESP_OK;
}
return err;
}
zhangyanjiaoesp
Xiehanxin
Alvin1Zhang
Answers checklist.
IDF version.
v5.1
Operating System used.
Windows
How did you build your project?
VS Code IDE
If you are using Windows, please specify command line type.
PowerShell
Development Kit.
Custom Board, ESP32-DEVKITV1, ESP-WROVER-KIT
Power Supply used.
USB
What is the expected behavior?
Mesh network should gracefully handle loss of connectivity or packet loss.
Any errors on loss of connectivity should be non blocking.
What is the actual behavior?
I am currently rewriting our firmware for v5.1 to hopefully fix some stability issues we've had in our previous firmware.
However, I am now facing a new problem. If there is poor mesh network connectivity, I will get the following error messages: W (154519) mesh: [mesh_schedule.c,3130] [WND-RX]max_wnd:2, 1800 ms timeout, seqno:0, xseqno:1, no_wnd_count:0, timeout_count:81
Through reading the bug reports, it seems this message means no TX window was given from the parent/root. To fix this, my units are free to disconnect from the mesh, find another parent or simply wait for the next sync window.
The problem arises because the TX window search seems to fully block my program, so I cannot disable the mesh or disconnect from the parent and search for another. I cannot gracefully restart either, the only thing I've found to be working is a task watchdog reboot.
This is my mesh enable function:
This is my mesh disable function:
Steps to reproduce.
Debug Logs.
More Information.
This problem did not seem to exist on our previos software which was running on v4.3, however as I've done a complete rewrite of the program there may be other factors affecting this.
I've also tried a lot of different things to handle this, however as far as I can tell, the moment I start getting RX window errors the only two things I've discovered that correct the problem is introducing another parent with a better signal for it to switch to automatically, or manually reboot the device.