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.
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.
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.
Previously ioctl was declared as a macro in lwip/sockets.h.
Disabling LWIP_POSIX_SOCKETS_IO_NAMES removed that declaration.
This adds sys/ioctl.h file and the missing declaration.
Also adds missing includes in vfs.c.
Reported from different sources from github or bbs:
https://github.com/espressif/esp-idf/issues/680https://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...
- uxTaskGetSystemState()
- uxTaskGetTaskNumber()
- vTaskSetTaskNumber()
- xEventGroupClearBitsFromISR()
- xEventGroupSetBitsFromISR()
- uxEventGroupGetNumber()
- uxQueueGetQueueNumber()
- vQueueSetQueueNumber()
- ucQueueGetQueueType()
Test cases for the following functions were not required...
- prvListTaskWithinSingleList()
- prvWriteNameToBuffer()
- vTaskList()
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.
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).
