Ivan Grokhotkov [Tue, 21 Feb 2017 13:57:53 +0000 (21:57 +0800)]
spi_flash: protect esp_intr_noniram_{disable,enable} in 1-core config
MR !441 (7c155ab) has fixed issue with esp_intr_noniram_{disable,enable}
calls not being properly protected by spi_flash_op_{lock,unlock}.
Unit test was added, but the unit test environment tests only dual-core
config. Similar issue was present in the code path for the single-core
config, where esp_intr_noniram_{disable,enable} calls were unprotected.
This change fixes the protection issue and updates the unit test to
run properly in single core config as well.
The issue with running unit tests for single core config will be
addressed in a separate MR.
Tian Hao [Fri, 17 Feb 2017 11:24:58 +0000 (19:24 +0800)]
component/bt : add bt enable/disable for power save
1. add new APIs bt controller enable/disab/deinit
2. make bt controller work need to call two APIs of esp_bt_controller_init and enable
3. modify phy init to make mac reset once
Merge branch 'bugfix/btdm_iphone10_0_2' into 'master'
Bugfix/btdm iphone10 0 2
This connection error caused by iPhone, it think that TX data length must large than 27 when slave support EXTEND_DATA_LENGTH. But this should be allow. Besides, the problem cannot be found on higher version of Iphone7, apple seemed to have fixed it.
Actually maybe other BLE device have the same problem.
Tian Hao [Thu, 16 Feb 2017 06:10:44 +0000 (14:10 +0800)]
component/bt : fix connection bug of Iphone7 10.0.2
This connection error caused by iPhone, it think that TX data length must large than 27 when slave support EXTEND_DATA_LENGTH. But this should be allow. Besides, the problem cannot be found on higher version of Iphone7, apple seemed to have fixed it.
Actually maybe other BLE device have the same problem.
Ivan Grokhotkov [Wed, 15 Feb 2017 05:26:22 +0000 (13:26 +0800)]
Merge branch 'bugfix/phy_init_write_nvs_once' into 'master'
phy_init: don’t rewrite valid calibration data
In the default PHY init routine, calibration data is loaded from NVS.
Most of the time the incremental changes to calibration will be fairly
small, so we don’t need to rewrite the existing calibration data stored
in the NVS.
Possible enhancement to be done in the future: expose a function in PHY
library to tell how big was the change in calibration data. If the
change was significant, then calibration data stored in NVS should be
updated.
Ivan Grokhotkov [Wed, 15 Feb 2017 05:25:51 +0000 (13:25 +0800)]
Merge branch 'bugfix/fix_protection_of_queue_list' into 'master'
freertos: fix protection issue in freertos queue event list
When functions in queue.c calls listLIST_IS_EMPTY() to check queue event list, the queue list is
protected by queue mutex, on the other hand, when xTaskIncrementTick() modify the queue list, the
queue list is protected by xTaskQueueMutex, this may cause xTaskRemoveFromEventList operate on
the empty queue list and cause problem.
This change works around the problem by reducing the window where the race condition can happen.
Merge branch 'bugfix/update_wifi_lib_to_include_some_fix_and_optimization' into 'master'
esp32: update wifi lib for some fixes and optimizations
1. Reduce the default static rx buffer size from 25 to 10
2. Adjust ampdu interrupt size to 3, namely, raise 1 interrupt per 3-mpdu
3. Make a copy for all received packets, including AMSDU/AMPDU/MPDU
4. Fix softap mis-forward issue
5. Fix pp q full issue
6. Fix sniffer copy wrong content issue
Liu Zhi Fu [Tue, 24 Jan 2017 12:40:14 +0000 (20:40 +0800)]
freertos: fix protection issue in freertos queue event list
When functions in queue.c calls listLIST_IS_EMPTY() to check queue event list, the queue list is
protected by queue mutex, on the other hand, when xTaskIncrementTick() modify the queue list, the
queue list is protected by xTaskQueueMutex, this may cause xTaskRemoveFromEventList operate on
the empty queue list and cause problem. This commit is to fix this bug.
Liu Zhi Fu [Fri, 10 Feb 2017 02:28:03 +0000 (10:28 +0800)]
esp32: update wifi lib for some fixes and optimizations
1. Reduce the default static rx buffer size from 25 to 10
2. Adjust ampdu interrupt size to 3, namely, raise 1 interrupt per 3-mpdu
3. Make a copy for all received packets, including AMSDU/AMPDU/MPDU
4. Fix softap mis-forward issue
5. Fix pp q full issue
6. Fix sniffer copy wrong content issue
Jeroen Domburg [Wed, 8 Feb 2017 04:19:34 +0000 (12:19 +0800)]
Merge branch 'bugfix/yield_other_core_prio_check_fix' into 'master'
Fix interrupting task on other CPU that has lower prio than current task on current CPU
Fix for a very subtle bug introduced somewhere in december. This bug would cause a cross-core interrupt to only be sent if the activated task has a higher priority than the task currently running on *this* cpu, instead of on the other CPU.
Ivan Grokhotkov [Tue, 7 Feb 2017 07:14:45 +0000 (15:14 +0800)]
phy_init: don’t rewrite valid calibration data
In the default PHY init routine, calibration data is loaded from NVS.
Most of the time the incremental changes to calibration will be fairly
small, so we don’t need to rewrite the existing calibration data stored
in the NVS.
Possible enhancement to be done in the future: expose a function in PHY
library to tell how big was the change in calibration data. If the
change was significant, then calibration data stored in NVS should be
updated.
He Yin Ling [Thu, 2 Feb 2017 13:59:00 +0000 (21:59 +0800)]
CI: get test env config from gitlab
Previous design was put test env config on local runners. It's not easy
to manage as test runners count growing. Now we'll put config files for
test runners to a Gitlab repository. Test runners will get its config
from Gitlab every time before running.
Angus Gratton [Fri, 27 Jan 2017 00:33:16 +0000 (08:33 +0800)]
Merge branch 'bugfix/spi_multiple_cs_fix' into 'master'
Add missing variable initialisation to make SPI work for multiple CS
Ref https://github.com/espressif/esp-idf/pull/277
From PR: "I am not especially familiar with this platform or with esp-idf -- so review with care.
The spi-master driver would not work for me when the number of devices on a bus exceeded 1 (caused device hang). I believe this is because cur_cs is not properly set (anywhere), and yet is used. This is likely just not noticed because 0 is presumably the correct value when there's only 1 device (and I'm guessing multi-device setup is not tested as thoroughly).
Simply setting cur_cs to the correct slot value resolves the problem and multiple devices on a single bus behave correctly in my test environment."
Merge branch 'bugfix/fix_two_wifi_datapath_issues' into 'master'
esp32: udpate wifi lib to fix two datapath issues
1. fix ampdu<->mpdu<->ampdu switch may cause rx slow issue by put mpdu into ampdu reorder queue
2. fix each ac first sending always fail issue by adding retry
Liu Zhi Fu [Thu, 26 Jan 2017 07:35:04 +0000 (15:35 +0800)]
esp32: udpate wifi lib to fix two datapath issues
1. fix ampdu<->mpdu<->ampdu switch may cause rx slow issue by put mpdu into ampdu reorder queue
2. fix each ac first sending always fail issue by adding retry
Angus Gratton [Thu, 26 Jan 2017 07:29:18 +0000 (18:29 +1100)]
Flash encryption: Temporary fix for issue with stale cache reads
Seems doing certain kinds of short reads while flash encryption is
enabled will return stale data. This fixes it, but is probably a
little heavy-handed performance wise.
Merge branch 'lwip/optimize_dhcpc_taken_time' into 'master'
lwip: optimize the dhcp client
1. modify the discover retry backoff time from (2,4,8,16,32,60,60)s to (500m,1,2,4,8,15,15)s.
2. add DHCP_DOES_ARP_CHECK to menuconfig for users to specify if do a ARP check on the offered address.
If enable, one more second will be taken.
qiyueixa [Sun, 22 Jan 2017 12:32:39 +0000 (20:32 +0800)]
lwip: optimize the dhcp client
1. modify the discover retry backoff time from (2,4,8,16,32,60,60)s to (500m,1,2,4,8,15,15)s.
2. add DHCP_DOES_ARP_CHECK to menuconfig for users to specify if do a ARP check on the offered address.
If enable, one more second will be taken in obtaining IP address.
3. update wifi libs
Angus Gratton [Thu, 5 Jan 2017 04:51:02 +0000 (15:51 +1100)]
spi_flash: Flush flash cache if flash_mmap()ing a written-to page
Without this, it's possible for stale information to be read from
cache via mmap, even if the MMU table entry had been invalidated
prior to writing flash (if the same MMU table entry was re-used after
writing flash.)