Commit graph

20 commits

Author SHA1 Message Date
Ivan Grokhotkov
43b5fdd5c9 soc/rtc: fix switching between 80/160 and 240MHz
Previous code contained a check for PLL frequency to be 240MHz, while
in fact 240MHz was a CPU frequency; corresponding PLL frequency is
480MHz. Fixed the comparison and replaced integer MHz values with an
enum.
2018-03-27 10:55:59 +08:00
Ivan Grokhotkov
887b6e2925 Merge branch 'bugfix/rtc_clk_32k_bootstrap' into 'master'
bugfix/rtc_clk_32k_bootstrap: Fix starting 32k RTC

See merge request idf/esp-idf!2085
2018-03-21 18:38:49 +08:00
Konstantin Kondrashov
f7df532ec0 bugfix/rtc_clk_32k_bootstrap: Fix starting 32k RTC
1. External 32kHz crystal is started for too long or it may not start at all. It is often observed at the first start.
2. At the first start, it is possible that the crystal did not start. And the recorded period was recorded as 0. Which led to a division error by zero during the transition to the deep sleep mode (Maybe somewhere else).
3. Added a unit test to test a new method of oscillation an external crystal.
4. Added a new method of oscillating of an external crystal. The legs of the crystal are fed with a 32 kHz frequency.

The new method eliminates these errors.

Added unit test: `\esp-idf\components\soc\esp32\test\test_rtc_clk.c`: `make TEST_COMPONENTS=soc`
- 8 Test starting external RTC crystal. Will pass.

`Bootstrap cycles for external 32kHz crystal` - is specified in the file Kconfig by default 100.

QA tested a new method of oscillation the crystal on 25 boards. The supply of square waves on the crystal showed a 100% result in contrast to the previous method of launching the crystal. After the tests, the old method was deleted.

Closes TW19143
2018-03-21 13:27:56 +05:00
Ivan Grokhotkov
1618dbc9a5 soc/rtc: wait for frequency switch to complete
The fast path of CPU frequency switch function, used in DFS, was not
waiting for the frequency switch to complete when switching from XTAL
to PLL. This resulted in incorrect reads from peripherals on APB,
where two consecutive reads could return the same value. For example,
in esp_timer, read of FRC_COUNT_REG would return same value as the
preceding read of FRC_ALARM_REG, causing time to jump by the value of
FRC_ALARM_REG / apb_freq_mhz.
2018-03-20 18:27:32 +08:00
Ivan Grokhotkov
7c584e80b0 soc/rtc_clk: fix loss of precision in estimation of XTAL frequency
RTC_FAST_CLK_FREQ_APPROX is defined as 8500000, so 0.5MHz part was lost
when dividing by MHZ. Since cal_val is 64-bit the parens can be removed.

With 40MHz XTAL for a nominal ESP32 chip, this fixes estimated XTAL
frequency from 38 to 40MHz.
2018-01-08 23:31:21 +08:00
Ivan Grokhotkov
3369f15fa3 soc/rtc: don't power down BIAS_I2C along with APLL if other PLL is used
If enable == false, and SOC_CLK_SEL == PLL, the code would would
erroneously set RTC_CNTL_BIAS_I2C_FORCE_PD. This change fixes the logic.
2017-11-20 15:27:16 +08:00
Ivan Grokhotkov
f22c681c1c soc/rtc: raise core voltage when 80MHz flash frequency is used
To achieve reliable operation with GD flash at 80MHz, need to raise
core voltage.
This causes the following current consumption increase:

At 80MHz: from 29mA to 33mA
At 160MHz: from 41mA to 47mA

Test conditions: 2 cores running code from IRAM, remaining peripherals
clock gated.
2017-11-08 21:13:02 +08:00
Ivan Grokhotkov
f11ad0c904 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.
2017-10-26 19:53:53 +08:00
Ivan Grokhotkov
6d4ed4ff6c 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.
2017-10-26 19:53:53 +08:00
Ivan Grokhotkov
b03e08dc4e soc/rtc: add function to convert CPU frequency in MHz to rtc_cpu_freq_t 2017-10-18 14:19:15 +08:00
Ivan Grokhotkov
a242ae6d0b soc/rtc: add fast paths for switching between PLL and XTAL 2017-10-18 14:19:14 +08:00
michael
9d9e771933 fix(global, log): fix esp_log(_early)_timestamp readings after startup by correct the CCOUNT register when switching CPU clock.
TW#13332, Closes #700
2017-09-26 15:18:17 +08:00
Ivan Grokhotkov
5a88f90a33 soc/rtc: warn if detected XTAL frequency does not match configured one
Since 9a8c0392, XTAL frequency is set to 40MHz by default, and users
of 26MHz boards need to select 26MHz manually. Most users are not aware
of this change, and existing getting started guides do not mention that
XTAL frequency needs to be set for some boards. So users are left with
garbage output from UART without any clue what to check.

This change adds a warning in case specific XTAL frequency was set, and
it does not match automatically detected one. This should help users
fix the issue.
2017-09-11 11:42:26 +08:00
Ivan Grokhotkov
c743bdac88 soc/rtc: round APB clock frequency to nearest MHz 2017-09-01 10:34:36 +08:00
Tian Hao
26a3cb93c7 component/soc : move dport access header files to soc
1. move dport access header files to soc
2. reduce dport register write protection. Only protect read operation
2017-05-09 18:06:00 +08:00
Tian Hao
f7e8856520 component/esp32 : fix dualcore bug
1. When dual core cpu run access DPORT register, must do protection.
2. If access DPORT register, must use DPORT_REG_READ/DPORT_REG_WRITE and DPORT_XXX register operation macro.
2017-05-08 21:53:43 +08:00
Ivan Grokhotkov
6353bc40d7 Add support for 32k XTAL as RTC_SLOW_CLK source
- RTC_CNTL_SLOWCLK_FREQ define is removed; rtc_clk_slow_freq_get_hz
  function can be used instead to get an approximate RTC_SLOW_CLK
  frequency

- Clock calibration is performed at startup. The value is saved and used
  for timekeeping and when entering deep sleep.

- When using the 32k XTAL, startup code will wait for the oscillator to
  start up. This can be possibly optimized by starting a separate task
  to wait for oscillator startup, and performing clock switch in that
  task.

- Fix a bug that 32k XTAL would be disabled in rtc_clk_init.

- Fix a rounding error in rtc_clk_cal, which caused systematic frequency
  error.

- Fix an overflow bug which caused rtc_clk_cal to timeout early if the
  slow_clk_cycles argument would exceed certain value

- Improve 32k XTAL oscillator startup time by introducing bootstrapping
  code, which uses internal pullup/pulldown resistors on 32K_N/32K_P
  pins to set better initial conditions for the oscillator.
2017-04-26 12:43:22 +08:00
Ivan Grokhotkov
3323f31cfb soc: implement XTAL frequency detection
ROM code already implements XTAL frequency detection, but it uses the 8M
clock before the clock tuning parameters are initialized. With the
zero clock tuning parameter, 8M clock has significant frequency deviation
at high temperatures, which can lead to erroneous detection of 40 MHz
crystal as a 26 MHz one.

This change adds XTAL frequency detection code to rtc_clk_init routine,
and detection is performed after the 8M clock tuning parameter as been
initialized.
2017-04-24 15:29:30 +08:00
Ivan Grokhotkov
6e9d60ef70 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).
2017-04-21 10:33:58 +08:00
Ivan Grokhotkov
7ee8ee8b7e soc: add source code of rtc_clk, rtc_pm 2017-04-11 15:45:54 +08:00