39cf3638ae
Previously, if CONFIG_FREERTOS_ENABLE_STATIC_TASK_CLEAN_UP was enabled, users would provide a definition for a vPortCleanUpTCB() hook function that is called right before a task's memory is freed in prvDeleteTCB(). However, vPortCleanUpTCB() will be reclaimed by ESP-IDF for internal use in v6.0. This commit introduces the following changes... Introduced a new CONFIG_FREERTOS_TASK_PRE_DELETION_HOOK option: - Provides the same pre-deletion hook functionality. But users now define vTaskPreDeletionHook() instead. - CONFIG_FREERTOS_ENABLE_STATIC_TASK_CLEAN_UP still exists, but is marked as deprecated. This is to maintain compatibility with existing applications that already define vPortCleanUpTCB(). - Removed redundant --wl --wrap workaround with vPortCleanUpTCB() - Added todo notes to remove support for user defined vPortCleanUpTCB() completely in v6.0. - Updated test cases to use new CONFIG_FREERTOS_TASK_PRE_DELETION_HOOK option Freed up portCLEAN_UP_TCB() to call a new internal vPortTCBPreDeleteHook(): - vPortTCBPreDeleteHook() now replaces the previous "wrapped" implementation of vPortCleanUpTCB(). - vPortTCBPreDeleteHook() is an internal task pre-delete hook for IDF FreeRTOS ports to inject some pre-deletion operations. - Internal pre-delete hook now invokes user provided vTaskPreDeletionHook() if enabled. - Relocated vPortTCBPreDeleteHook() to correct section in port.c |
||
---|---|---|
.. | ||
build_system | ||
configs | ||
linux_compatible | ||
peripherals/i2c_wifi | ||
phy | ||
protocols | ||
security/secure_boot | ||
system | ||
.build-test-rules.yml | ||
README.md |
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.ci
and similar (see below) - Python test scripts,
pytest_....py
(optional)
Test Apps layout
The test apps should be grouped into subdirectories by category. Categories are:
protocols
contains test of protocol interactions.network
contains system network testssystem
contains tests on the internal chip features, debugging and development tools.security
contains tests on the chip security features.
CI Behavior
Configuration Files
For each project in test_apps (and also examples):
- If a file
sdkconfig.ci
exists then it's built as thedefault
CI 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 * n
configuration 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.defaults
file or a file namedsdkconfig.defaults.<TARGET>
appended. (Same as a normal ESP-IDF project build.)
Test Apps local execution
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