The issue is `esp_flash_write_encryped` function in ROM on ESP32C3, ESP32S3
calls legacy implementation, which uses old configuration. And this causes
write fails.
The solution in this commit is to compile and link this function(and related)
in IRAM instead of the ROM one.
The IRAM cost increases around 1.2KB after the fix
Prior to this change, `spi_flash_hal_supports_direct_write` and
`spi_flash_hal_supports_direct_read` will check the buffer pointer
place, which should be done in driver layer, instead of HAL layer.
esp_timer:
Control flow issues (DEADCODE)
Execution cannot reach this statement: "break;".
protocomm_httpd:
(UNUSED_VALUE)
Assigning value from "cookie_session_id" to "cur_cookie_session_id" here, but that stored value is overwritten before it can be used.
esp_flash_api:
Null pointer dereferences (REVERSE_INULL)
Null-checking "chip" suggests that it may be null, but it has already been dereferenced on all paths leading to the check.
There is a periodically yield in the esp_flash driver, to ensure the
cache will not be disabled for too long on ESP32.
On ESP32-S2 and later, we need to support more different kind of yield:
1. polling conditions, including timeout, SW read request, etc.
2. wait for events, including HW done/error/auto-suspend, timeout
semaphore, etc.
The check_yield() and yield() is separated into two parts, because we
may need to insert suspend, etc. between them.
Including:
1. Change the write bytes/read bytes parameter in the host driver into slicers to meet the requirements of complicated cases.
2. Refactor the esp_flash_api code a bit so that we can use the code in the ROM laster
3. Provide get_temp_buffer and release_temp_buffer in the os_functions when the buffer passed by application cannot be used directly.
4. Make timeout of operations configurable in the chip_driver.
5. Make dummy number configurable.
Flash write operation is broken down into smaller chunk writes. Size
of this chunk was previously set to 8K but that in-turn meant cache and
non-IRAM resident interrupts could stay disabled upto ~24msec for 8K flash
write operation. If chunk size is brought down to 256 (typical flash page size)
then it brings down cache and non-IRAM interrupts disable duration to ~1msec.
Fix here keeps defaults same but provides configuration option to tweak the
setting based on application requirement.
The SPI bus lock on SPI1 introduces two side effects:
1. The device lock for the main flash requires the
`CONFIG_FREERTOS_SUPPORT_STATIC_ALLOCATION` to be selected, however this
option is disabled by default in earlier IDF versions. Some developers
may find their project cannot be built by their old sdkconfig files.
2. Usually we don't need the lock on the SPI1 bus, due to it's
restrictions. However the overhead still exists in this case, the IRAM
cost for static version of semaphore functions, and the time cost when
getting and releasing the lock.
This commit:
1. Add a CONFIG_SPI_FLASH_BYPASS_MAIN_LOCK option, which will forbid the
space cost, as well as the initialization of the main bus lock.
2. When the option is not selected, the bus lock is used, the
`CONFIG_FREERTOS_SUPPORT_STATIC_ALLOCATION` will be selected explicitly.
3. Revert default value of `CONFIG_FREERTOS_SUPPORT_STATIC_ALLOCATION`
to `n`.
introduced in 49a48644e4.
Closes https://github.com/espressif/esp-idf/issues/5046
Allocation of the temporary internal buffer will now repeat until a small enough buffer can be
allocated, and only fail if less than a 256 byte block of internal RAM is free.
Adds unit test for the same, and generic test utility for creating memory pressure.
Previously would try allocate buffer of minimum size 16KB not maximum size 16KB, causing
out of memory errors for any large reads, or if less than 16KB contiguous free heap.
Also, if using legacy API and internal allocation failed then implementation would abort()
instead of returning the error to the caller.
Added test for using large buffers in PSRAM.
Closes https://github.com/espressif/esp-idf/issues/4769
Also reported on forum: https://esp32.com/viewtopic.php?f=13&t=14304&p=55972
There used to be dummy phase before out phase in common command
transactions. This corrupts the data.
The code before never actually operate (clear) the QE bit, once it finds
the QE bit is set. It's hard to check whether the QE set/disable
functions work well.
This commit:
1. Cancel the dummy phase
2. Set and clear the QE bit according to chip settings, allowing tests
for QE bits. However for some chips (Winbond for example), it's not
forced to clear the QE bit if not able to.
3. Also refactor to allow chip_generic and other chips to share the same
code to read and write qe bit; let common command and read command share
configure_host_io_mode.
4. Rename read mode to io mode since maybe we will write data with quad
mode one day.
