- Add support for esp32s2, esp32c3 and esp32c2 for the `memprot`-related tests
- Preliminary support for esp32s3 has also been added,
the test app will be enabled for esp32s3 later when
the memprot-related issues are fixed.
- Override panic handler to dump the violation intr status
- Dump the `memprot` violation registers before calling the
real panic handler
- Handle `Illegal Instruction` exception in case of memprot permission violation
* In esp32c3 with `memprot` enabled, if we try to execute arbitrary code
from RTC_FAST_MEM we get an `Illegal Instruction` exception from the panic
handler rather than a `Memory Protection Fault`.
* This is because the Illegal Instruction interrupt occurs earlier than the
memory protection interrupt due to a higher interrupt latency.
Test Apps
This directory contains a set of ESP-IDF projects to be used as tests only, which aim to exercise various configuration of components to check completely arbitrary functionality should it be building only, executing under various conditions or combination with other components, including custom test frameworks.
The test apps are not intended to demonstrate the ESP-IDF functionality in any way.
Test Apps projects
Test applications are treated the same way as ESP-IDF examples, so each project directory shall contain
- Build recipe in cmake and the main component with app sources
- Configuration files,
sdkconfig.ciand similar (see below) - Test executor in
ttfw_idfformat if the project is intended to also run tests (otherwise the example is build only)- test file in the project dir must end with
_test.py, by should be namedapp_test.py - test cases shall be decorated with
@ttfw_idf.idf_custom_test(env_tag="...")
- test file in the project dir must end with
Test Apps layout
The test apps should be grouped into subdirectories by category. Categories are:
protocolscontains test of protocol interactions.networkcontains system network testssystemcontains tests on the internal chip features, debugging and development tools.securitycontains tests on the chip security features.
CI Behavior
Configuration Files
For each project in test_apps (and also examples):
- If a file
sdkconfig.ciexists then it's built as thedefaultCI config. - If any additional files
sdkconfig.ci.<CONFIG>exist then these are built as alternative configs, with the specified<CONFIG>name.
The CI system expects to see at least a "default" config, so add sdkconfig.ci before adding any sdkconfig.ci.CONFIG files.
- By default, every CI configurations is built for every target SoC (an
m * nconfiguration matrix). However if anysdkconfig.ci.*file contains a line of the formCONFIG_IDF_TARGET="targetname"then that CI config is only built for that one target. This only works insdkconfig.ci.CONFIG, not in the defaultsdkconfig.ci. - Each configuration is also built with the contents of any
sdkconfig.defaultsfile or a file namedsdkconfig.defaults.<TARGET>appended. (Same as a normal ESP-IDF project build.)
Test Execution
If an example test or test app test supports more targets than just ESP32, then the app_test.py file needs to specify the list of supported targets in the test decorator. For example:
@ttfw_idf.idf_example_test(env_tag='Example_GENERIC', target=['esp32', 'esp32s2'])
def test_app_xyz(env, extra_data):
If the app test supports multiple targets but you only want some of these targets to be run automatically in CI, the list can be further filtered down by adding the ci_target list:
@ttfw_idf.idf_example_test(env_tag='Example_GENERIC', target=['esp32', 'esp32s2'], ci_target=['esp32'])
def test_app_xyz(env, extra_data):
(If no ci_target list is specified, all supported targets will be tested in CI.)
Test Apps local execution (ttfw)
All the following instructions are general. Part of them may be complemented by more particular instructions in the corresponding app's README.
Requirements
Install Python dependencies and export the Python path where the IDF CI Python modules are found with the following commands:
bash install.sh --enable-ttfw
source export.sh
export PYTHONPATH=$IDF_PATH/tools/ci/python_packages:$PYTHONPATH
You should also set the port via the environment variable ESPPORT to prevent the tools from looking and iterating over all serial ports. The latter causes much trouble, currently:
export ESPPORT=/dev/ttyUSB<X>
Execution
- Create an sdkconfig file from the relevant
sdkconfig.ci.<CONFIG>andsdkconfig.defaults:cat sdkconfig.defaults sdkconfig.ci.<CONFIG> > sdkconfig - Run
idf.py menuconfigto configure local project attributes - Run
idf.py buildto build the test app - Run
python app_test.pyto run the test locally
Test Apps local execution (pytest)
Some of the examples have pytest_....py scripts that are using the pytest as the test framework. For detailed information, please refer to the "Run the Tests Locally" Section under ESP-IDF tests in Pytest documentation
Using pytest is the recommended way to write new tests. We will migrate all the test apps scripts to this new framework soon.