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.
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.
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.
If VDDSDIO is controlled by RTC (which is the case when using 1.8V flash
and CONFIG_BOOTLOADER_VDDSDIO_BOOST is enabled), need to allow VDDSDIO
to be controlled by the state machine before going into deep sleep.
1. raise vddsdio for 1.8v flash
2. gpio matrix config for flash
3. fix esp_restart function
todo:
to decide whether to raise core voltage
to test deep-sleep current
1. Name change from chopper to carrier, block diagram update, minor changes to example codes
2. mcpwm_reg.h changed, brought uniformity in comments, worked on suggestions, duty to accept float. Some name changes!
3. Minor readme changes and Indetation
4. Minor change: move mcpwm_reg.h and mcpwm_struct.h to new path
5. Minor change: addition of BLDC example code and Readme
6. Name changed from epwm to mcpwm
7. Improve the reg name in mcpwm_struct.h
8. Name change chopper>carrier, deadband>deadtime
add API to get chip info
This change adds an API to get chip info, such as chip model, enabled capabilities, size of embedded flash, silicon revision.
Hello_world example is modified to print out the information about the chip. The example is also simplified by moving all code into the main task.
Ref TW12031.
See merge request !549
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.
Split common SPI stuff out of master driver; add slave driver; add workaround for DMA issue.
This merge req mainly adds a slave device. In order to do this, the original master driver is refactored into common code shared by master and slave modes, and a slave driver is added.
The other things added are:
- Added a workaround for a 'feature' of the ESP32 silicon that can lock up the receive DMA channel in some situations. This can only be fixed by resetting *both* DMA channels. The workaround implemented makes sure that the reset only happens when both channels are idle
- Got rid of the automatic choice between register- and DMA-based transfers. The master (and slave) code will now always go for a DMA transfer if a DMA channel is given, and always go for register-based transfers if no DMA channel is given.
- Add in a bunch of fixes for outstanding Github issues.
See merge request !659
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.
Ref TW11683.
Ref https://esp32.com/viewtopic.php?f=13&t=1570
Fixes https://github.com/espressif/esp-idf/issues/337.
See merge request !696
- 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.
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.
soc: allow REG_SET_FIELD to be used for bit fields
- Fixes an issue with `rtc_clk_apll_enable`: https://esp32.com/viewtopic.php?f=13&t=1673
- Fixes `rtc_clk_fast_freq_set` function always selecting XTAL/4 as fast clock source.
- Fixes regression in deep sleep current (7uA instead of 5uA).
See merge request !674
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).
