Reported from github:
https://github.com/espressif/esp-idf/issues/1219https://github.com/espressif/esp-idf/issues/1202
After providing a simple code to digital team, they confirmed that this is a hardware bug.
Root cause:
The fifo reset signal is incorrectly connected
If we want to reset tx fifo of UART2, we have to set txfifo_rst bit of both UART1 and UART2
If we want to reset rx fifo of UART2, we have to set rxfifo_rst bit of both UART1 and UART2
Workaround:
we don't use fifo rst bit in driver.
Documentation:
Digital team would update TRM and give more explanation about this issue.
1. V366, fix a problem which initialize current can reach 800mA.
2. V365, fix a problem for pll_cap tracking in Coexist (BT & WIFI)
mode. The problem will make Coexist (BT & WIFI) WIFI AP mode TX
Fail in high temperature(>70).
3. V364, fix a bug of BT and Wifi coexist (hung in function of
force_wifi_mode())
component/bt: Fix the bug of master don't send pair request to the slave when the sec_act set to the value of ESP_BLE_SEC_ENCRYPT.
See merge request !1376
1. move settings of WIFI_CLK_EN_REG for bluetooth into controller init/deinit APIs
2. modify the bit mask used in phy_rf init/deinit to use WIFI-BT shared bits
This commit updates various test cases throughout esp-idf such that
the values used for timer divider pass the assertions in the timer component.
Timer divider values must be between 2 to 65536
Previously esp_restart would stall the other CPU before enabling RTC_WDT.
If the other CPU was executing an s32c1i instruction, the lock signal
from CPU to the arbiter would still be held after CPU was stalled. If
the CPU running esp_restart would then try to access the same locked
memory pool, it would be stuck, because lock signal would never be
released.
With this change, esp_restart resets the other CPU before stalling it.
Ideally, we would want to reset the CPU and keep it in reset, but the
hardware doesn't have such feature for PRO_CPU (it is possible to hold
APP_CPU in reset using DPORT register). Given that ROM code will not use
s32c1i in the first few hundred cycles, doing reset and then stall seems
to be safe.
In addition to than, RTC_WDT initialization is moved to the beginning of
the function, to prevent possible lock-up if CPU stalling still has any
issue.
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.
