1. separate rom include files and linkscript to esp_rom
2. modefiy "include rom/xxx.h" to "include esp32/rom/xxx.h"
3. Forward compatible
4. update mqtt
This commit removes trailing semicolons following a while(0) from
function-like macros in IDF. This will force those macros to be called
with a semicolon when called.
In some cases, when data was just written into UART FIFO, transmitter
state could be still zero while the FIFO did contain some data.
This resulted in uart_tx_wait_idle occasionally returning before all
the data was sent out.
Fix by checking both UART transmitter state and TX FIFO count.
* Fixes some "noreturn" functions in bootloader utils which did return (causing fatal CPU
exceptions).
* Marks bootloader entry as "noreturn", preventing "user code done" from stalling boot
Partial fix for https://github.com/espressif/esp-idf/issues/1814 TW20016
(Comprehensive fix for this issue will be enabling WDT during bootloader, coming shortly.)
1. Bootloader reads SPI configuration from bin header, so that the burning configuration can be different with compiling configuration.
2. Psram mode init will overwrite original flash speed mode, so that users can change psram and flash speed after OTA. 3. Flash read mode(QIO/DIO…) will not be changed in app bin. It is decided by bootloader, OTA can not change this mode.
4. Add read flash ID function, and save flash ID in g_rom_flashchip
5. Set drive ability for all related GPIOs
6. Check raise VDDSDIO voltage in 80Mhz mode
7. Add check flash ID and update settings in bootloader
8. Read flash ID once and keep in global variable
9. Read flash image header once and reuse the result
Tested cases:
1. Test new and old version of bootloader
boot Flash 20M —> app Flash 80M + Psram 80M
boot Flash 40M —> app Flash 80M + Psram 80M
boot Flash 80M —> app Flash 80M + Psram 80M
boot Flash 20M —> app Flash 80M + Psram 40M
boot Flash 40M —> app Flash 80M + Psram 40M
boot Flash 80M —> app Flash 80M + Psram 40M
boot Flash 20M —> app Flash 40M + Psram 40M
boot Flash 40M —> app Flash 40M + Psram 40M
boot Flash 80M —> app Flash 40M + Psram 40M 2. Working after esp_restart reboot.
Small changes to clock calibration value will cause increasing errors
the longer the device runs. Consider the case of deep sleep, assuming
that RTC counter is used for timekeeping:
- before sleep:
time_before = rtc_counter * calibration_val
- after sleep:
time_after = (rtc_counter + sleep_count) * (calibration_val + epsilon)
where 'epsilon' is a small estimation error of 'calibration_val'.
The apparent sleep duration thus will be:
time_after - time_before = sleep_count * (calibration_val + epsilon)
+ rtc_counter * epsilon
Second term on the right hand side is the error in time difference
estimation, it is proportional to the total system runtime (rtc_counter).
To avoid this issue, this change makes RTC_SLOW_CLK calibration value
persistent across restarts. This allows the calibration value update to
be preformed, while keeping time after update same as before the update.
Confusion here is that original ROM has two functions:
* SPIReadModeCnfig() - sets mode, calls enable_qio_mode/disable_qio_mode
* SPIMasterReadModeCnfig() - As above, but doesn't set QIO mode in status register
However we never want to use the ROM method to set/clear QIO mode flag, as not all flash chips work this way. Instead we
do it in flash_qio_mode.c in bootloader.
So in both cases (ROM or "patched ROM") we now call SPIMasterReadModeCnfig(), which is now named
esp_rom_spiflash_config_readmode().
Introduce soc component, add source of rtc_clk and rtc_pm libraries
This MR adds parts of the RTC library source code (initialization, clock selection functions, sleep functions). WiFi-related power management functions are kept inside the precompiled library. Most of RTC library APIs have been renamed.
Default CPU frequency option in Kconfig is set to 160MHz, pending qualification of 240MHz mode at high temperatures.
Register header files are moved into the new soc component, which will contain chip-specific header files and low-level non-RTOS-aware APIs (such as rtc_ APIs). Some of the files from ESP32 component were also moved: cpu_util.c, brownout.c, and the corresponding header files. Further refactoring of ESP32 component into more meaningful layers (chip-specific low level functions; chip-specific RTOS aware functions; framework-specific RTOS-related functions) will be done in future MRs.
See merge request !633
1) fixed SPI_read_status: added check for flash busy flag in matrix mode
2) fixed SPI_page_program: enable write before writing data to SPI FIFO
3) SPI flash ROM funcs replacement is controlled via menuconfig option
Deep sleep stub may call ets_update_cpu_frequency, which has been moved from ROM to IRAM.
Restore the ROM version in the linker script, call it ets_update_cpu_frequency_rom, use it in the deep sleep stub.
Flash encryption support
Flash encryption support in build system, tooling
To come in future MR:
* On-device key generation on first boot (for production devices), need to finalise testing of bootloader entropy seeding.
* spi_flash_encrypted_write to support non-32-byte block writes (at least optionally.)
* I think a lot of the bootloader_support component can possibly be rolled into "spiflash" and other components, to use a common API.
See merge request !240
- ROM function uart_tx_wait_idle may have a bug which causes the function to return before the final character is fully transmitted.
This replaces uart_tx_wait_idle declaration with a static inline definition which fixes the issue.
- Also replaces the use of uart_tx_flush with uart_tx_wait_idle in esp_restart, to remove garbage in console output on restart.
- rtc_printf is temporary replaced with a no-op, pending a new release of librtc.a. Current release assumes that UART0 is used for output,
and switches UART0 baud rate while doing frequency changes and printing some log output. This doesn’t work if a different UART is used for output.
* App access functions are all flash encryption-aware
* Documentation for flash encryption
* Partition read/write is flash aware
* New encrypted write function
SHA acceleration integrated to mbedTLS incl. TLS sessions
Uses hardware SHA acceleration where available, fails over to software where not available.
Ref TW7112
See merge request !232
spi_flash_erase_range: Allow for 32KB blocks not 64KB blocks
SPI flash hardware sends 52h command, which is a 32KB erase.
There is a matching bug in the ROM SPIEraseArea code, unless
flashchip->block_size is modified first.
See merge request !249
SPI flash hardware sends 52h command, which is a 32KB erase.
There is a matching bug in the ROM SPIEraseArea code, unless
flashchip->block_size is modified first.
SHA hardware allows each of SHA1, SHA256, SHA384&SHA512 to calculate digests
concurrently.
Currently incompatible with AES acceleration due to a hardware reset problem.
Ref TW7111.
We reserve 4KB Slow RTC memory to save RF calibation result and BT NVS data.
If not all these Slow RTC momory Blocks are used, we will open the other parts.
App can contain a stub program resident in RTC fast memory. Bootloader
will load the stub on initial boot. If the device wakes from deep sleep,
the stub is run immediately (before any other data is loaded, etc.)
To implement a custom wake stub, implement a function in your program:
```
void RTC_IRAM_ATTR esp_wake_deep_sleep(void)
{
esp_default_wake_deep_sleep();
// other wake logic
}
```
... and it will replace the default implementation.
morris