esp_wifi_connect() does not yield to other tasks? (GIT8266O-176)

[metadata1984]

Environment
Development Kit:Node Mcu
IDF version (git rev-parse --short HEAD to get the commit id.): V3.1
Development Env: Eclipse
Operating System: Windows
Power Supply: USB
Problem Description

测试项目给予 esp8266_rtos_3.1 。测试代码中带两个任务.任务1 使用examples的http_request事例不停连接测试地址，任务2驱动led屏幕。任务2优先级11.

测试代码中，任务2不停刷新液晶屏幕。测试发现当任务1执行完esp_wifi_connect()后。任务2液晶被挂起大约1s左右。

当串口输出如下日志后，任务2重新执行。
[18:47:52.699]收←◆scandone

[18:47:53.705]收←◆state: 0 -> 2 (b0)
state: 2 -> 3 (0)

[18:47:53.754]收←◆state: 3 -> 5 (10)
add 0
aid 5
pm open phy_2,type:2 0 0
cnt

---

任务2中的关键代码

IRAM_ATTR void tm3130_send_data(uint32_t data)
{
TM_DIN_PIN_GPIO_LOW();
// ets_delay_us(200);

// ETS_NMI_LOCK();
ETS_INTR_LOCK();

for(register volatile uint8_t i = 0; i< 32;i++){
	TM_DIN_PIN_GPIO_HIGH();

	if(data & TM_DATA_MASK){

// asm volatile("nop;nop;");
TM_ONE_HIGH_DELAY();
TM_DIN_PIN_GPIO_LOW();
TM_ONE_LOW_DELAY();
}else{
// asm volatile("nop;nop;");
TM_ZERO_HIGH_DELAY();
TM_DIN_PIN_GPIO_LOW();
TM_ZERO_LOW_DELAY();
}

	data >>= 1;
}
TM_DIN_PIN_GPIO_HIGH();
ETS_INTR_UNLOCK();
ets_delay_us(5);
TM_DIN_PIN_GPIO_LOW();

// ETS_NMI_UNLOCK();
ets_delay_us(200);
TM_DIN_PIN_GPIO_HIGH();

}

按照文档说明，esp_event_loop的优先级为10，但是任务2的优先级为11.按理可抢占。但测试发现任务2被暂停接近1s。 此问题应如何解决？

[donghengqaz]

连接 Wi-Fi 的时候会有 13-14 优先级的 task 用于计算 Wi-Fi 的 key，这个时间暂时没有办法优化。

[dsptech]

esp8266/Arduino#6136

Hi @donghengqaz ,
I'm also dealing against this issue, on the arduino FW and here, on RTOS framework.
When using RTOS framework , I discovered that the issue sometime does not occur (sometime I have 900ms of latency on user task, and other times 30-40ms only).
I suppose that the issue is related in some way to the access point configuration. Have you more infomation on that ?
Anyway, I will continue to investigate on it.
Regards.

[metadata1984]

could you please seperate the task to small pieces ？It's Unacceptable in real time control system 。
BTW，I could that rtos_sdk_release v2.1 has no problem。 Why？

[dsptech]

Hi @metadata1984 , hi @donghengqaz,

I investigated a bit more. I'm not longer able to reproduce the issue related to a succesfully connection, but using instead a right ssid with a WRONG password, the issue is always present: 900 ms of latency on ANY task priority level (0 to 14).
The true problem is that xPortSysTickHandle (port.c) cease to receive the Timer 0 interrupt shots and therefore xTaskIncrementTick (task.c) is not longer called.

So, we are loosing the freertos scheduler at all, the idle / tick hooks and the freertos tick count too.
Note: in these conditions, xTaskGetTickCount is not suitable to detect the latency due the missed tick increments, but soc_get_ticks() is able perform the job instead.

I also seen that the critical sections (vPortEnterCritical and vPortExitCritical (port.c)) are supposed to stops interrupts on level 1 only, but it seems to me to the used portDISABLE_INTERRUPTS macro is disabling up to the level 3 instead (hardware timers).

Anyway, vPortEnterCritical and vPortExitCritical are not related to the latency (a logic analyzer confirmed it to me), so, the true issue must be located elsewhere, likely in the closed wifi driver.
... it seems to me a bug.

[dsptech]

missed information: tests performed using clock: 160Mhz, freertos freq.: 250Hz. I will try soon to lower the frequency to 100hz freq. in search of changes of the issue.
for @metadata1984: which freertos frequency are you using ?

[dsptech]

Update: changing the freertos frequency does nothing. I also confirm that all hardware interrupts are disabled, even Timer 1 interrupts.
In these conditions, there is not way to deal any time critical condition without disabling the wifi.

[donghengqaz]

I mean that when do the Wi-Fi connection, the software will close the hardware interrupt and get AP's information and do some calculation, and this behavior should cost some time, so not only task switch but also other hardware interrupt is pending.

[dsptech]

Hi @donghengqaz
I opened a new issue about interrupts before reading your reply. Sorry.
The interrupt disabling has also side effects on timing.

[metadata1984]

il

cpu frq： 80MHZ，freertos frq default settings。

[metadata1984]

I found anther similar issue today。IT may be useful。
Env：esp8266 rtos sdk v2.1.0
CPU frq 80MHZ，freertos frq 100
task1（priority :11）： os_print “running” and delay 100 ms。
task2（priority :2）： connect wifi ap。

when task2 code like that:

wifi_station_set_config_current(&stationConf); // here
wifi_station_connect();

the task1 block about 1s。

then i change the code

wifi_station_set_config(&stationConf); // here
wifi_station_connect();

burn the firmware and start ，task1 block about 1s in first system boot。
reboot the system ，the issue disappear。。。。。。。
reboot the system 2nd 。3rd。。。。。，the issue disappear。。。。。。。

what ‘s the wrong。。。。。。。。。。。
so confuse 。。。。。。。。。。。

[metadata1984]

BTW
there is more info

burn the firmware and start system
the log output

scandone

block 1s。

but reboot the system the log output

reconnect
scandone

the blocking issue disappear。。。

[dsptech]

Hi @metadata1984,
have you disabled the flash storage in the wifi driver ?
The wifi driver could try to auto connect when booting, and the latency could be already occurred when your tasks are starting.
Furthermore, you cannot rely on xTaskGetTickCount() and esp_timer_get_time() to evaluate the latency because these functions are halted too and do not recover the right value. Only soc_get_ccount() work fine.
See the above referenced issue for more information.

[FayeY]

Closing due to lack of response, please feel free to reopen if this is still an issue. Thanks.