Ivan Grokhotkov [Thu, 26 Oct 2017 10:52:00 +0000 (18:52 +0800)]
soc/rtc: fix spurious warnings about XTAL frequency on startup
1. Make sure that 8MD256 clock used to estimate XTAL frequency is enabled
before trying to use rtc_clk_cal_ratio.
This fixes "Bogus XTAL frequency: 0 MHz" warnings after software reset.
2. Don't call rtc_clk_xtal_freq_estimate if XTAL frequency is already
known. This reduces startup time after deep sleep or software reset.
3. Compare known XTAL frequency and estimated one before printing a
warning. This fixes "Possibly invalid CONFIG_ESP32_XTAL_FREQ setting
(40MHz). Detected 40 MHz." warnings.
Ivan Grokhotkov [Thu, 26 Oct 2017 10:46:27 +0000 (18:46 +0800)]
soc/rtc: wait for SLOW_CLK cycle when switching CPU clock
Previous implementation waited for 20us after setting
RTC_CNTL_SOC_CLK_SEL_XTL register, using ets_delay_us, assuming that
the CPU was running at XTAL frequency. In reality, clock switch happened
on the next RTC_SLOW_CLK cycle, and CPU could be running at the previous
frequency (for example, 240 MHz) until then.
ets_delay_us would wait for 20 us * 40 cycles per us = 800 CPU cycles
(assuming 40 MHz XTAL; even less with a 26 MHz XTAL).
But if CPU was running at 240 MHz, 800 cycles would pass in just 3.3us,
while SLOW_CLK cycle could happen as much as 1/150kHz = 6.7us after
RTC_CNTL_SOC_CLK_SEL_XTL was set. So the software would not actually wait
long enough for the clock switch to happen, and would disable the PLL
while CPU was still clocked from PLL, leading to a halt.
This implementation uses rtc_clk_wait_for_slow_cycle() function to wait
until the clock switch, removing the need to wait for a fixed number of
CPU cycles.
Ivan Grokhotkov [Thu, 26 Oct 2017 10:33:13 +0000 (18:33 +0800)]
soc/rtc: add a function to wait for slow clock cycle
Some RTC features are synchronized to RTC_SLOW_CLK, so sometimes
software needs to wait for the next slow clock cycle.
This function implements waiting using Timer Group clock calibration
feature.
bugfix(i2c): add I2C hardware reset if the hw FSM get stuck
Reported from different sources from github or bbs:
https://github.com/espressif/esp-idf/issues/680
https://github.com/espressif/esp-idf/issues/922
We tested reading several sensor or other I2C slave devices, if the power and SDA/SCL wires are in proper condition, everything works find with reading the slave.
If we remove the power supply for the slave during I2C is reading, or directly connect SDA or SCL to ground, this would cause the I2C FSM get stuck in wrong state, all we can do is the reset the I2C hardware in this case.
After this commit, no matter whether the power supply of I2C slave is removed or SDA / SCL are shorted to ground, the driver can recover from wrong state.
We are not sure whether this the save issue with the reported one yet, but to make the driver more robust.
Further information:
1. For I2C master mode, we have tested different situations, e.g., to short the SDA/SCL directly to GND/VCC, to short the SDA to SCL, to un-plug the slave device, to power off the slave device. Under all of those situations, this version of driver can recover and keep working.
2. Some slave device will die by accident and keep the SDA in low level, in this case, master should send several clock to make the slave release the bus.
3. Slave mode of ESP32 might also get in wrong state that held the SDA low, in this case, master device could send a stop signal to make esp32 slave release the bus.
Modifications:
1. Disable I2C_MASTER_TRAN_COMP interrupt to void extra interrupt.
2. Disable un-used timeout interrupt for slave.
3. Add bus reset if error detected for master mode.
4. Add bus clear if SDA level is low when error detected.
5. Modify the argument type of i2c_set_pin.
6. add API to set timeout value
7. add parameter check for timing APIs
This commit makes configUSE_TRACE_FACILITY and
configUSE_STATS_FORMATTING_FUNCTIONS configurable in kconfig. Test cases fro the
functions enabled by the two configurations above have also been added.
Test cases for the following functions have been added...
Ivan Grokhotkov [Wed, 18 Oct 2017 04:18:38 +0000 (12:18 +0800)]
soc: correct values of SOC_BYTE_ACCESSIBLE_LOW, SOC_MEM_INTERNAL_LOW
Internal byte accessible memory starts with Internal ROM 1 at 0x3FF90000.
Region of RTC fast memory starting at 0x3FF80000 is not used in IDF as
it is mapped to PRO CPU only.
Angus Gratton [Thu, 19 Oct 2017 07:59:04 +0000 (15:59 +0800)]
heap: Fix race condition causing malloc() to fail under some conditions
During a call to multi_heap_malloc(), if both these conditions were true:
- That heap only has one block large enough for the allocation
(this is always the case if the heap is unfragmented).
- Another allocation is simultaneously occurring in the same heap.
... multi_heap_malloc() could incorrectly return NULL.
This caused IDF heap_caps_malloc() and malloc() to also fail, particularly
often if only one or two heaps had space for the allocation (otherwise
heap_caps_malloc() fails over to the next heap).
Angus Gratton [Wed, 18 Oct 2017 06:54:55 +0000 (14:54 +0800)]
heap: Fix spurious heap_caps_check_integrity() errors in Comprehensive mode
Heap was not being locked before poisoning, so heap_caps_check_integrity()
would sometimes race with checking the poison bytes and print unnecessary
errors.
Deng Xin [Tue, 17 Oct 2017 06:57:45 +0000 (14:57 +0800)]
esp32: fix some wifi bugs
1. Fix WiFi timer enable twice issue
2. Fix a softAP compatibility issue
3. Fix ebuf alloc counter issue
4. remove nvs_flash_init() in esp_wifi_init()
5. Fix scan only find few APs after set bssid
6. Fix can not connect to hidden SoftAP
7. Remove group key entry before connecting ot AP
projects / esp-idf / log