Previously the DROM_HIGH_ADDR for esp32s3 was 0x3D000000, which
convers only 16 MB of address range. But esp32s3 supports 32 MB
external memory. So this address should be 0x3E000000
Previously, "soc/chip_revision.h" contained a static assert to check that the
CONFIG_ESP_REV_MIN_FULL <= CONFIG_ESP_REV_MAX_FULL. There are two issues with
this assert:
- Contained in a header file, so it is only compiled if the "chip_revision.h"
is included somewhere
- CONFIG_ESP_REV_MIN_FULL and CONFIG_ESP_REV_MAX_FULL are defined in
"esp_hw_support", which is a G0 component. This creates a reverse dependency
of G0 on G1.
This commit moves the static assert "revision.c" in "esp_hw_support"
eFuse module has a hardware bug.
It is related to ESP32-C3, C6, S3, H2 chips:
- BLOCK9 (BLOCK_KEY5) can not be used by XTS_AES keys.
For H2 chips, the BLOCK9 (BLOCK_KEY5) can not be used by ECDSA keys.
S2 does not have such a hardware bug.
- As per the memory block diagram for ESP32-S3, the
internal memory address ranges as follows:
DRAM: 0x3FC88000 (== SOC_MEM_INTERNAL_LOW) <-> 0x3FCF0000
IRAM: 0x40378000 <-> 0x403E0000 (== SOC_MEM_INTERNAL_HIGH)
- to acknowledge the unused DCACHE added to DRAM for ESP32-S3
- For ESP32-S3, when the DCACHE size is set to 16 kB, the unused 48 kB is added to
the heap in 2 blocks of 32 kB (from 0x3FCF0000) and 16 kB (from 0x3C000000).
- But, if we try allocating memory from the 16 kB block and run an `esp_ptr_internal`
check on that memory pointer, it fails as the address block from 0x3C000000
corresponds to the external memory symbols SOC_DROM_LOW and SOC_EXTRAM_DATA_LOW.
(E.g. freertos - If the IDLE task stack buffer gets allocated from this region,
the firmware will abort due to this failure).
- Thus, the checks `esp_ptr_internal`, `esp_ptr_in_drom` and `esp_ptr_byte_accessible`
have been updated to acknowledge this memory as a part of the DRAM.
Co-authored-by: Mahavir Jain <mahavir@espressif.com>
1. Fix deep sleep wakeup IOs can not be unhold issue
2. Correct hold related APIs' description
3. Fix gpio_force_hold_all API
docs: Add GPIO wakeup source to sleep_modes doc for ESP32C3
Following the file renaming to use the "usb_dwc" prefix, this commit
updates the symbol names of those files to use the "usb_dwc" as well.
Some LL functions were also renamed so that the register name is
mentioned.
This commit updates the DWC_OTG based struct/ll/hal file names to
use the prefix "usb_dwc". This naming scheme reduces ambiguity if
another USB controller implementation is added.
As a result, "hcd.c" has been renamed to "hcd_dwc.c"
Bluetooth low power related logic and regs have separate power domain from MAC and BB,
and do not power down during light sleep. If reset when power up MAC and BB in sleep
flow, it may destroy the state of bt low power part.