Tickless idle/light sleep procedure had a bug in single core mode.
Consider the flow of events:
1. Idle task runs and calls vApplicationIdleHook
2. This calls esp_vApplicationIdleHook, which calls esp_pm_impl_idle_hook, and pm lock for RTOS on the current core is released.
3. Then esp_vApplicationIdleHook calls esp_pm_impl_waiti, which checks that s_entered_light_sleep[core_id]==false and goes into waiti state.
4. Some interrupt happens, calls esp_pm_impl_isr_hook, which takes pm lock for RTOS. PM state goes back to CPU_FREQ_MAX.
5. Once the interrupt is over, vApplicationIdleHook returns, and Idle task continues to run, finally reaching the call to vApplicationSleep.
6. vApplicationSleep does not enter light sleep, because esp_pm_impl_isr_hook has already changed PM state from IDLE to CPU_FREQ_MAX.
This didn’t happen in dual core mode, because waiti state of one CPU was interrupted by CCOMPARE update interrupt from the other CPU, in which case PM lock for FreeRTOS was not taken.
Fix by inverting the meaning of the flag (for convenience) and only setting it to true when vApplicationSleep actually fails to enter light sleep.
Having two different spinlocks is problematic due to possibly
different order in which the locks will be taken. Changing the order
would require significant restructuring of kernel code which is
undesirable.
An additional place where taking xTickCountMutex was needed was in
vApplicationSleep function. Not taking xTickCountMutex resulted in
other CPU sometimes possibly advancing tick count while light sleep
entry/exit was happening. Taking xTickCountMutex in addition to
xTaskQueueMutex has shown a problem that in different code paths,
these two spinlocks could be taken in different order, leading to
(unlikely, but possible) deadlocks.
1. When WIFI task or other high priority task blocks the Bluetooth task, ACL RX buffer will use up, ACL RX buffer ptr will point to null and will never point to a valid adress. Causing errors in Bluetooth.
2. hcimsgs.h used whether flow control is on or off
Introduced in 97e3542947.
The previous commit frees the IRAM part when single core, but doesn't
change the memory layout functions. The unit test mallocs IRAM memory
from the heap, accidently into the new-released region, which doesn't
match the memory layout function.
This commit update the memory layout function to fix this.
Problem Decribe
The problem happenned when do wps with a mikrotik router
1. router always want to do connect with 32 without EAP-WSC step
2. after 4 way timeour, 32 crash
Root Cause
The reason why can not start EAP-WSC step is router's check method is RSN > WPA > WPS, when it found there include RSN and WPS in assoc, it will choice do 4 way rather than WPS
The reason of second problem is 32's EAPOL start timer didn't stop and send EAPOL start to a null pointer
Soultion
1. remove RSN and WPA ie when do WPS step
2. check mac address's pointer before send EAPOL start
closes: https://github.com/espressif/esp-idf/issues/2382
