Some logging done in soc component may happen before logging via
stdout is possible. Use _EARLY version of log calls to make sure that
output is visible. The downside is that application does not have a
way to silence these logs. However since the soc component doesn’t
use any LOGV/LOGD/LOGI and only logs warnings and errors, this should
not impact the application.
When CONFIG_ESP32_RTCDATA_IN_FAST_MEM is enabled, RTC data is placed
into RTC_FAST memory region, viewed from the data bus. However the
bootloader was missing a check that this region should not be
overwritten after deep sleep, which caused .rtc.bss segment to loose
its contents after wakeup.
Works for 3.3V eMMC in 4 line mode.
Not implemented:
- DDR mode for SD cards (UHS-I) also need voltage to be switched to 1.8V.
- 8-line DDR mode for eMMC to be implemented later.
Previous APIs used to set CPU frequency used CPU frequencies listed in
rtc_cpu_freq_t enumeration. This was problematic for two reasons.
First, supporting many possible frequency values obtained by dividing
XTAL frequency was hard, as every value would have to be listed in
the enumeration. Since different base XTAL frequencies are supported,
this further complicated things, since not all of these divided
frequencies would be valid for any given XTAL frequency. Second,
having to deal with enumeration values often involved switch
statements to convert between enumeration and MHz values, handle
PLL/XTAL frequencies separately, etc.
This change introduces rtc_cpu_freq_config_t structure, which contains
CPU frequency (in MHz) and information on how this frequency has to
be generated: clock source (XTAL/PLL), source frequency, clock
divider value. More fields can be added to this structure in the
future. This structure simplifies many parts of the code, since both
frequency value and frequency generation settings can be accessed in
any place in code without the need for conversions.
Additionally, this change adds setting of REF_TICK dividers to support
frequencies lower then XTAL with DFS.
1. BLE only with 9(max) connection will decrease 3K DRAM
2. BR/EDR only with 7(max) connection will decrease 16K DRAM
3. Any of BLE or BR/EDR connection number decrease will also decrease DRAM consumption
4. Decrease one BLE connection will save about 1KB DRAM
5. Decrease one BR/EDR ACL connection will save about 1.2KB DRAM
6. Decrease one BR/EDR SCO/eSCO will save 2KB DRAM.
7. fix some definition and kconfig
8. remove 1.2k of vhci tx cache and make .bss & .data to heap about 1.4K
9. modify BT Reserved Memory size and modify example to support new bt kconfig
For pins 32 and up the BIT(nr) macro used here overflowed,
causing undetermined GPIO pins to be reset.
Example: freeing SPI device/bus where CS is on pin 33
caused debug UART to cease communication, TXD0 was
disabled.
Fixed as BIT64(nr) macro, to be used elsewhere as needed.
For example in definitions like GPIO_SEL_32..GPIO_SEL_39.
No longer necessary to keep all reserved addresses in 'soc'.
Means 'soc' does not need to know about 'bt', for example.
Also means that Bluetooth can be enabled in config without any memory being reserved for BT
controller. Only if code calling the BT controller is linked in, will this memory be reserved...
Fixed the error division on zero.
Also fixed range CONFIG_ESP32_RTC_CLK_CAL_CYCLES in Kconfig.
Fixed a overflow error by TIMG in the function rtc_clk_cal_internal. This error was due to a limit in values TIMG_RTC_CALI_MAX=0x7FFF (to write the slowclk_cycles) and TIMG_RTC_CALI_VALUE=0x1FFFFFF (to read xtal_cycles). Added assert finctions.
Closes https://github.com/espressif/esp-idf/issues/2147
