Getting a beacon timeout

[ekalyvio]

Hello, I am using an altered version of the http_server example and in my program, I have a task running like the following:

void analyzer_task(void *pvParameter)
{
    for (;;) {
        // Calc data here...
        // ............
        // Send data here...
        xQueueSendToBack(tsDataQueue, response, 0);
        // ............
        vTaskDelay(50 / portTICK_PERIOD_MS);
    }

    vTaskDelete(NULL);
}

When I do a delay of 50ms with the vTaskDelay, every 5-10 seconds the program disconnects from the WiFi and returns the following strings into the console. beacon timeout rm match scandone add 0 aid 2 cnt

If I reduce the delay to lets say 10ms, then the problem appears almost instantly. Any idea of what this might be?

[ourairquality]

fwiw I had been seeing this when testing the malloc-regions patch, but thought it had been due to a problem fixed there. Were you testing the master branch?

Is there any chance of narrowing down a simple example that might reproduce for other people, to give us some chance of narrowing down the problem?

Are you running any tasks at a high priority that might starve the pp task or timer task?

Does it reproduce if the wifi connection is closer?

[ekalyvio]

Yes. I was working on the master branch. I will try to narrow down a simple example in the next week. Yes, I have 2 tasks that are running but both have some 50msec vTaskDelay and as such, they shouldn't starvate any other tasks. Of course, when I reduce the delay, the error occurs more frequently. The error still occurs even when the device is 10cm over the router (maybe much less often, I am not sure). I also changed manually from my router the Beacon Interval from 100 to 40 (the minimum) and the error started coming less frequently. The same problem occurs even when the device is operating in Access point mode and I connect to it directly from the computer. The device is an Adafruit Feather Huzzah ESP-12S.

[tkremeyer]

Hi @ekalyvio, this issue is somewhat older, but since it is still open: Did you manage to narrow down the problem in the mean time? I experienced the same problem and created a somewhat minimal example. It seems that in my case the issue is related to the FreeRTOS tick rate.

#include <espressif/esp_common.h>
#include <esp8266.h>
#include <esp/uart.h>
#include <string.h>
#include <stdio.h>
#include <FreeRTOS.h>
#include <task.h>

void task(void *pvParameters) {
    for(;;) {
        printf("test\n");  //just a visual check that the tick rate is correct
        vTaskDelay(10000 / portTICK_PERIOD_MS);
    }
}

void user_init(void) {
    uart_set_baud(0, 115200);
    printf("SDK version:%s\n", sdk_system_get_sdk_version());
    printf("Tick Period: %d\n", portTICK_PERIOD_MS);
    printf("Tick Rate: %d\n", configTICK_RATE_HZ);

    struct sdk_station_config config = {
        .ssid = "my_wifi",
        .password = "secretsecret",
    };

    /* required to call wifi_set_opmode before station_set_config */
    sdk_wifi_set_opmode(STATION_MODE);
    sdk_wifi_station_set_config(&config);
    sdk_wifi_station_connect();

    /* initialize tasks */
    xTaskCreate(task, "Task", 256, NULL, 2, NULL);
}

This example works without issue for the default tick rate of 100Hz. However, if I modify the file esp-open-rtos/FreeRTOS/Source/include/FreeRTOSConfig.h as such:

#define configTICK_RATE_HZ                      ( ( TickType_t ) 1000 )

the problem appears.

Since I have the tick rate at 1000 in my project code, I will try to reduce it and see if this was the only problem.

Note that creating a file named FreeRTOSConfig.h in my project folder with this option and #include_next<FreeRTOSConfig.h> didn't suffice, since apparently the FreeRTOS Scheduler doesn't use this file and that way the tick rate becomes inconsistent.

[ekalyvio]

No. Unfortunately I did not find where the problem was. I had to switch to a different hardware to do my job as this one seemed to me totally unreliable.

[tkremeyer]

I made a further test with my application which is using more tasks and also some critical sections. Changing the tick rate to 100Hz also seems to solve the problem there.

@UncleRus Since I've had this problem for months and only just found the reason, I think it's a good idea to document this, for example in the Troubleshooting section - just a quick note that a too high tick rate might be a bad idea. What do you think?