"wifi" taks aborts - stack overflow

[jhinkle]

I'm using esp32-prog in vscode to debug.

Had skdconfig set to compile in debug.

Found debugging was not what I wanted as many lines of code were optimized out.

Set skdconfig to debug-no optimization.

As soon as I start the app - I get a panic fault identifying task on core 0 with name "wifi" experienced a stack overflow.

Searching forums and google - did not find a solution.

Did a search of all files in the esp-components folder for any task with name "wifi" - found none (must be in the binary blob).

Thought it might be associated with logging - so I disabled all logging in skdconfig.

Fault still occurs. I don't want to debug with optimization - but for now I must.

Does espressif have any thoughts or solution to increasing the stack size on the task called "wifi" so the app can be debug with no optimization?

Thanks.

[jhinkle]

I've been trying to jtag debug but it is worthless!!!
All the variables I need to track their value or buffer location to display what's in memory are optimized out.

I tried the old-fashion method of using logging - I place a vtaskdelay of 250 msec between each line - and it just gets confused so the debugging info acquired is useless.

I have a buffer read from spisd and a buffer write to spi (EE) - but both buffers are optimized out so I can't see exactly why there are incorrect.

The setting of debug-no optimization would work but as stated earlier - a blob task name "wifi" faults almost immediately with a stack over-flow.

Any suggestions???

[boarchuz]

Increase the WiFi task stack size. It's set either through menuconfig or as a field in the WiFi init config (I can't recall which). If the latter, you're probably using the WIFI_INIT_CONFIG_DEFAULT() macro but evidently the default stack size is insufficient for your build config.

[jhinkle]

Thanks for your reply but neither of the two you mentioned address the issue.

sdk menu does NOT have an entry to set the "wifi" task stack size. As a test, In revised every stack setting in menu incase the naming did not correspond to "wifi".

I set debug-no-optimization and found the where xTaskCreate is actually being called (so I could check the call stack and see where and see what value they were setting for stack size).

The "wifi" task IS being created within the MAIN APP call to r = esp_wifi_init(&cfg);

The cfg struct does NOT have an entry for task stack size.

Tracing into esp_wifi_init(&cfg) - this function gets called (result = esp_wifi_init_internal(config);) There is NO source on esp_wifi_init_internal - it is part of the ESP32 internal binary blob.

Setting a break point at xTaskCreate - I can break as the "wifi" task is being created. Looking at the call stack and working backwards - the call to xTaskCreate is inside the binary blob.

Stack size of "wifi" is 3584.

Any thoughts?

struct for cfg

Code: Select all

/**
 * @brief WiFi stack configuration parameters passed to esp_wifi_init call.
 */
typedef struct {
    wifi_osi_funcs_t*      osi_funcs;              /**< WiFi OS functions */
    wpa_crypto_funcs_t     wpa_crypto_funcs;       /**< WiFi station crypto functions when connect */
    int                    static_rx_buf_num;      /**< WiFi static RX buffer number */
    int                    dynamic_rx_buf_num;     /**< WiFi dynamic RX buffer number */
    int                    tx_buf_type;            /**< WiFi TX buffer type */
    int                    static_tx_buf_num;      /**< WiFi static TX buffer number */
    int                    dynamic_tx_buf_num;     /**< WiFi dynamic TX buffer number */
    int                    rx_mgmt_buf_type;       /**< WiFi RX MGMT buffer type */
    int                    rx_mgmt_buf_num;        /**< WiFi RX MGMT buffer number */
    int                    cache_tx_buf_num;       /**< WiFi TX cache buffer number */
    int                    csi_enable;             /**< WiFi channel state information enable flag */
    int                    ampdu_rx_enable;        /**< WiFi AMPDU RX feature enable flag */
    int                    ampdu_tx_enable;        /**< WiFi AMPDU TX feature enable flag */
    int                    amsdu_tx_enable;        /**< WiFi AMSDU TX feature enable flag */
    int                    nvs_enable;             /**< WiFi NVS flash enable flag */
    int                    nano_enable;            /**< Nano option for printf/scan family enable flag */
    int                    rx_ba_win;              /**< WiFi Block Ack RX window size */
    int                    wifi_task_core_id;      /**< WiFi Task Core ID */
    int                    beacon_max_len;         /**< WiFi softAP maximum length of the beacon */
    int                    mgmt_sbuf_num;          /**< WiFi management short buffer number, the minimum value is 6, the maximum value is 32 */
    uint64_t               feature_caps;           /**< Enables additional WiFi features and capabilities */
    bool                   sta_disconnected_pm;    /**< WiFi Power Management for station at disconnected status */
    int                    espnow_max_encrypt_num; /**< Maximum encrypt number of peers supported by espnow */
    int                    tx_hetb_queue_num;      /**< WiFi TX HE TB QUEUE number for STA HE TB PPDU transmission */
    bool                   dump_hesigb_enable;     /**< enable dump sigb field */
    int                    magic;                  /**< WiFi init magic number, it should be the last field */
} wifi_init_config_t;

[boarchuz]

Sorry for leading you astray, you're right it doesn't seem to be configurable. In that case your options are to provide a custom task creation function via wifi_init_config_t::osi_funcs or wrap the FreeRTOS task create function using the linker --wrap option.

This is worthy of an issue on GitHub if you are so inclined. Clearly this stack size needs to either automatically adjust to support the standard optimisation options or allow developers to easily set it manually.

[jhinkle]

I really appreciate your reply. It made me take the next step.

I totally agree that this issue needs to be addressed. The more you search into it - I'm NOT the first. There are many other post about this issue - maybe not properly identifying the root cause - but they are there. There are post in the github on the same issue.

Espressif does not seem to want to address it.

Your two proposed solutions ARE the correct way to resolve my issue -- but I took a different approach - I modified the IDF source.

Code: Select all

#if ( configSUPPORT_DYNAMIC_ALLOCATION == 1 )

    BaseType_t xTaskCreatePinnedToCore( TaskFunction_t pxTaskCode,
                                        const char * const pcName,
                                        const uint32_t usStackDepth,
                                        void * const pvParameters,
                                        UBaseType_t uxPriority,
                                        TaskHandle_t * const pxCreatedTask,
                                        const BaseType_t xCoreID )
    {
        BaseType_t xReturn;

        configASSERT( taskVALID_CORE_ID( xCoreID ) == pdTRUE || xCoreID == tskNO_AFFINITY );

void Modify_xTaskCreate_StackSize(char *N, uint32_t *SZ);
        Modify_xTaskCreate_StackSize(pcName, (uint32_t*)&usStackDepth);

Code: Select all

void Modify_xTaskCreate_StackSize(char *N, uint32_t *SZ)
{
    if(strcmp("wifi", N) == 0)
        *SZ = 5120;
}

Now I can modify any task I like - it works great. I have resolved my issue. I just need to modify the next version of the IDF if I every choose to update it.

Again - thanks for taking your time to reply.