]> granicus.if.org Git - esp-idf/commit
Merge branch 'bugfix/xtal_freq_after_wdt_reset' into 'master'
authorIvan Grokhotkov <ivan@espressif.com>
Fri, 21 Apr 2017 11:38:46 +0000 (19:38 +0800)
committerIvan Grokhotkov <ivan@espressif.com>
Fri, 21 Apr 2017 11:38:46 +0000 (19:38 +0800)
commit8399ed900aae2108ef9b82f6466a04e159d72171
treec1a3bbc218ad122b34e72597801b35f1999d30e1
parentfd3ef4cdfe1ce747ef4757205f4bb797b099c9d9
parent6e9d60ef70703795b03f0e5f4fc82291cb75362c
Merge branch 'bugfix/xtal_freq_after_wdt_reset' into 'master'

rtc_clk_init: handle case when XTAL frequency has already been set

On first reset, ROM code writes the estimated XTAL frequency into
RTC_APB_FREQ_REG (aka STORE5). If the application doesn’t specify exact
XTAL frequency (which is always the case for now), rtc_clk_init will
guess what kind of XTAL is used (26M or 40M), based on the estimated
frequency. Later, detected frequency is written into RTC_XTAL_FREQ_REG
(aka STORE4).

When the application switches clock source to PLL, APB frequency changes
and RTC_APB_FREQ_REG is updated. If the application encounters an RTC
WDT reset, RTC_APB_FREQ_REG will not be updated prior to reset. Once the
application starts up again, it will attempt to auto-detect XTAL
frequency based on RTC_APB_FREQ_REG, which now has value of 80000000.
This will fail, and rtc_clk_xtal_freq_estimate will fall back to the
default value of 26 MHz. Due to an incorrect XTAL frequency, PLL
initialization will also take incorrect path, and PLL will run at a
different frequency. Depending on the application this may cause just
garbage output on UART or a crash (if WiFi is used).

This change checks if RTC_XTAL_FREQ_REG has already been set before trying
to estimate XTAL frequency based on the value of RTC_APB_FREQ_REG, and
uses RTC_XTAL_FREQ_REG value if it is valid.

Fixes TW11738.

See merge request !691