Timing Code With Cache Compensated Timer - Espressif ESP32-S2 Programming Manual

Chapter 4. API Guides
(18) "SPI Master DMA test, TX and RX in different regions"
(19) "SPI Master DMA test: length, start, not aligned"
(20) "reset reason check for deepsleep"
(1) "trigger_deepsleep"
(2) "check_deepsleep_reset_reason"
The normal case will print the case name and description. Master-slave cases will also print the sub-menu (the
registered test function names).
Test cases can be run by inputting one of the following:
• Test case name in quotation marks to run a single test case
• Test case index to run a single test case
• Module name in square brackets to run all test cases for a specific module
• An asterisk to run all test cases
[multi_device] and [multi_stage] tags tell the test runner whether a test case is a multiple devices or
multiple stages of test case. These tags are automatically added by `TEST_CASE_MULTIPLE_STAGES and
TEST_CASE_MULTIPLE_DEVICES macros.
After you select a multi-device test case, it will print sub-menu:
Running gpio master/slave test
gpio master/slave test example
(1) "gpio_master_test"
(2) "gpio_slave_test"
You need to input a number to select the test running on the DUT.
Similar to multi-device test cases, multi-stage test cases will also print sub-menu:
Running reset reason check
reset reason check for
(1) "trigger_deepsleep"
(2) "check_deepsleep_reset_reason"
First time you execute this case, input 1 to run first stage (trigger deepsleep). After DUT is rebooted and able to run
test cases, select this case again and input 2 to run the second stage. The case only passes if the last stage passes and
all previous stages trigger reset.

4.30.7 Timing Code with Cache Compensated Timer

Instructions and data stored in external memory (e.g. SPI Flash and SPI RAM) are accessed through the CPU's
unified instruction and data cache. When code or data is in cache, access is very fast (i.e., a cache hit).
However, if the instruction or data is not in cache, it needs to be fetched from external memory (i.e., a cache miss).
Access to external memory is significantly slower, as the CPU must execute stall cycles whilst waiting for the instruc-
tion or data to be retrieved from external memory. This can cause the overall code execution speed to vary depending
on the number of cache hits or misses.
Code and data placements can vary between builds, and some arrangements may be more favorable with regards to
cache access (i.e., minimizing cache misses). This can technically affect execution speed, however these factors are
usually irrelevant as their effect 'average out'over the device's operation.
The effect of the cache on execution speed, however, can be relevant in benchmarking scenarios (especially micro
benchmarks). There might be some variability in measured time between runs and between different builds. A tech-
nique for eliminating for some of the variability is to place code and data in instruction or data RAM (IRAM/DRAM),
respectively. The CPU can access IRAM and DRAM directly, eliminating the cache out of the equation. However,
this might not always be viable as the size of IRAM and DRAM is limited.
Espressif Systems
example...
for deepsleep...
deepsleep
1507
Submit Document Feedback
[spi]
[spi]
[esp32s2][test_env=UT_T2_1][multi_stage]
(continued from previous page)
Release v4.4