ESP32-C2 has a single group timer, thus it will use it for the interrupt watchdog,
which is more critical than the task watchdog. The latter is implement in
software thanks to the `esp_timer`component.
This commit adds support for using the RTC I2C peripheral on the ULP
RISC-V core for esp32s2 and esp32s3. It also adds an example to demonstrate the
usage of the RTC I2C peripheral.
This commit also modifies the rtc_i2c register structure files to enable
the use of bitfields in the ULP RISC-V RTC I2C driver.
update gpio_sig at `spics_out` array in each spi_periph.c of chips later than s2
then `spi_bus_add_device` can correctly distribute gpio_signals for cs_signal
Closes https://github.com/espressif/esp-idf/issues/8876
Wrap the ledc, i2c source files with the new caps in CMakeLists and linker.lf.
This could avoid potential source file not found warning during linking time.
Closes: https://github.com/espressif/esp-idf/issues/9208
When I2S is configured into different modes, the slot sequence varies.
This commit updates slot sequence tables and corresponding descriptions
in (both code and programming guide).
When ESP32-C2 is paired with a 26 MHz XTAL, the systimer tick
frequency becomes equal to 26 / 2.5 = 10.4 MHz. Previously we always
assumed that systimer tick frequency is integer (and 1 MHz * power of
two, above that!).
This commit introduces a new LL macro, SYSTIMER_LL_TICKS_PER_US_DIV.
It should be set in such a way that:
1. SYSTIMER_LL_TICKS_PER_US / SYSTIMER_LL_TICKS_PER_US_DIV equals the
actual systimer tick frequency,
2. and SYSTIMER_LL_TICKS_PER_US is integer.
For ESP32-C2 this means that SYSTIMER_LL_TICKS_PER_US = 52 and
SYSTIMER_LL_TICKS_PER_US_DIV = 5.
This introduced two possible issues:
1. Overflow when multiplying systimer counter by 5
- Should not be an issue, since systimer counter is 52-bit, so
counter * 5 is no more than 55-bit.
2. The code needs to perform:
- divide by 5: when converting from microseconds to ticks
- divide by 52: when converting from ticks to microseconds
The latter potentially introduces a performance issue for the
esp_timer_get_time function.
1. Rename MACROs SYSTEM_WIFI_RST_EN register bit fields to be more recognizable
2. reset Bluetooth baseband and clock bits to fix the issue of task watchdog triggered during controller initialization due to invalid hardware state
When creating G0 layer, some regi2c_*.h headers were moved out from
esp_hw_support (G1) to soc (G0). In order to be consistent with that change,
move all the remaining regi2c_*.h headers to soc too.
In C++20, using the result of an assignment to a 'volatile' value is
deprecated.
Breaking change: register "setter" or modification macros can no
longer be used as expressions.
Closes https://github.com/espressif/esp-idf/issues/9170
This commit updates the esp_cpu.h API. The new API presents a new
abstraction of the CPU where CPU presents the following interfaces:
- CPU Control (to stall/unstall/reset the CPU)
- CPU Registers (to read registers commonly used in SW such as SP, PC)
- CPU Interrupts (to inquire/allocate/control the CPUs 32 interrupts)
- Memory Port (to configure the CPU's memory bus for memory protection)
- Debugging (to configure/control the CPU's debugging port)
Note: Also added FORCE_INLINE_ATTR to the DoxyFile in order to pass doc
builds for esp_cpu.h
ESP32C3/ESP32S3: Fix cpu crash bug when wakeup from lightsleep for memory data miss
Closes IDF-162 and IDF-4923
See merge request espressif/esp-idf!17823
When enable sleep reject before this fix, we have two limitations:
1. it must be light sleep
2. RTC GPIO wakeup source must be set
We require light sleep because `esp_deep_sleep_start` function has
been declared with "noreturn" attribute, So developers don't expect
that this function may return (due to an error or a sleep reject).
But the requirement for RTC GPIO wakeup source is not reasonable for
all chips. This requirement exists because ESP32 only supports RTC GPIO
and SDIO sleep reject sources. But later chips support all sleep reject
sources.
This fix brings the following changes:
for ESP32: RTC GPIO and SDIO sleep reject sources can be enabled
when corresponding wakeup source is set.
for later chips: all sleep reject sources can be enabled when
corresponding wakeup source is set.
introduced in e44ead5356
1. The int8M power domain config by default is PD. While LEDC is using
RTC8M as clock source, this power domain will be kept on.
But when 8MD256 is used as RTC clock source, the power domain should
also be kept on.
On ESP32, there was protection for it, but broken by commit
e44ead5356. Currently the power domain
will be forced on when LEDC is using RTC8M as clock source &&
!int8m_pd_en (user enable ESP_PDP_DOMAIN_RTC8M in lightsleep). Otherwise
the power domain will be powered off, regardless of RTC clock source.
In other words, int8M domain will be forced off (even when 8MD256
used as RTC clock source) if LEDC not using RTC8M as clock source, user
doesn't enable ESP_PDP_DOMAIN_RTC8M, or in deep sleep.
On later chips, there's no such protection, so 8MD256 could't be used as
RTC clock source in sleep modes.
This commit adds protection of 8MD256 clock to other chips. Fixes the
incorrect protection logic overriding on ESP32. Now the power domain
will be determiend by the logic below (order by priority):
1. When RTC clock source uses 8MD256, power up
2. When LEDC uses RTC8M clock source, power up
3. In deepsleep, power down
4. Otherwise determined by user config of ESP_PDP_DOMAIN_RTC8M,
power down by default. (This is preferred to have highest
priority, but it's kept as is because of current code structure.)
2. Before, after the macro `RTC_SLEEP_CONFIG_DEFAULT` decides dbias, the
protection above may force the int8m PU. This may cause the inconsistent
of dbias and the int8m PU status.
This commit lifts the logic of pd int8m/xtal fpu logic to upper layer
(sleep_modes.c).
Related: https://github.com/espressif/esp-idf/issues/8007, https://github.com/espressif/esp-idf/pull/8089
temp
The legacy driver can't handle the breaking change between esp chips
very well.
And it's not elegant to extend new feature like DMA, ETM.
The new driver can return a opaque handle for each RMT channel.
An obvious transaction concept was also introduced.
TX and RX functionalities are splited out.
