qiyuexia [Wed, 31 Oct 2018 13:11:57 +0000 (21:11 +0800)]
mesh: update libs
1. fix ap_loss that occurs when the parent turns off the mesh function and becomes a normal WiFi with a different SSID.
2. add an event MESH_EVENT_NETWORK_STATE that contains information about whether there is a root in the current network.
3. modify the mechanism of mesh IE update.
4. fix a problem in the process of re-voting to select the root, the device that does not meet the conditions of being a root votes for itself.
5. fix an issue that occurs in esp_mesh_recv_toDS() when stopping the mesh.
6. when the user specifies a parent for the device, the device will set the authmode and password of its AP mode to the same value as the specified parent.
7. add two disconnected reason codes MESH_REASON_EMPTY_PASSWORD and MESH_REASON_PARENT_UNENCRYPTED.
morris [Mon, 15 Oct 2018 12:35:05 +0000 (20:35 +0800)]
ethernet: fix some bugs in phy&mac driver
1. Original register mapping for LAN8720 has some registers that doesn't exist/support.
So just remove them, and fix the power and init function for LAN8720.
2. GPIO16 and GPIO17 is occupied by PSRAM, so only ETH_CLOCK_GPIO_IN mode is supported in that case if using PSRAM.
3. Fix bug of OTA failing with Ethernet
4. Fix bug of multicast with Ethernet
This commit resolves a blocking in esp_aes_block function.
Introduce:
The problem was in the fact that AES is switched off at the moment when he should give out the processed data. But because of the disabled, the operation can not be completed successfully, there is an infinite hang. The reason for this behavior is that the registers for controlling the inclusion of AES, SHA, MPI have shared registers and they were not protected from sharing.
Fix some related issue with shared using of AES SHA RSA accelerators.
Ivan Grokhotkov [Thu, 1 Nov 2018 11:38:48 +0000 (19:38 +0800)]
pm: prevent entering light sleep again immediately after wakeup
When light sleep is finished on one CPU, it is possible that the other
CPU will enter light sleep again very soon, before interrupts on the
first CPU get a chance to run. To avoid such situation, set a flag
for the other CPU to skip light sleep attempt.
Ivan Grokhotkov [Tue, 30 Oct 2018 08:05:06 +0000 (16:05 +0800)]
pm: fix entering light sleep in single core mode
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.
Ivan Grokhotkov [Fri, 12 Oct 2018 06:18:49 +0000 (14:18 +0800)]
freertos: use xTaskQueueMutex to protect tick count
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.
baohongde [Thu, 1 Nov 2018 09:33:44 +0000 (17:33 +0800)]
components/bt: Point ACL RX buffer ptr to ACL RX buffer if ACL RX buffer ptr is null
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
wangmengyang [Tue, 30 Oct 2018 06:30:07 +0000 (14:30 +0800)]
component/bt: bugfix for the error in calculation sniff anchor point which can result in supervision timeout after connection is brought into sniff mode
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.
Deng Xin [Mon, 29 Oct 2018 07:28:32 +0000 (15:28 +0800)]
wifi: bugfix of assert when do wps with mikrotik
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
projects / esp-idf / log