Extend target checks in cmake, in case it's run directly and not via
idf.py or if idf.py misses something. This may happen
for example if cmake variables are set in project's CMakeLists.txt.
Some clean-ups are included along with the new checks and tests.
1. __target_check() function is removed. IIUC it should never fail,
because the selected target is explicitly passed as environmental
variable to kconfgen. Meaning the IDF_TARGET from environment variable may
not be actually used in kconfgen if IDF_TARGET is already set it cmake cache.
Note that the IDF_TARGET environment variable used for kconfgen is not
based on the actual IDF_TARGET environment variable set for idf.py, but
rather on the value set in __target_init() with
set(IDF_TARGET ${env_idf_target} CACHE STRING "IDF Build Target")
My understanding is that the original check was introduced to handle
situation, where IDF_TARGET was already set in cmake's cache and
the IDF_TARGET from environment variable was different. Since
the kconfgen would use the original environment variable(not
explicitly passed as it is now) the IDF_TARGET in cmake and in
sdkconfig could differ. IOW I think the original check was introduced
to cope with the following cmake behaviour
set(VARIABLE "value1" CACHE STRING "test variable")
set(VARIABLE "value2" CACHE STRING "test variable")
message("Variable value: ${VARIABLE}")
output: Variable value: value1
2. I scratched by head how it is possible that the following code
in __target_check()
if(NOT ${IDF_TARGET} STREQUAL ${env_idf_target})
could fail if IDF_TARGET is not set. For example in clean project
IDF_TARGET=esp32 idf.py reconfigure
Here env_idf_target==esp32 and IDF_TARGET is not set, so I would
expect that cmake will fail with error message that the cache
and env target do not match. The thing is that the variable
evaluation is done before the if command, so it actually
sees this
if(NOT STREQUAL esp32)
which is false and the error is not printed. It can be seen
with 'cmake --trace-expand' command. I don't know if this
was used on purpose or it worked just as a coincidence, but
I find it very confusing, so I added explicit check if the
IDF_TARGET is defined before the actual check. Same for
CMAKE_TOOLCHAIN_FILE.
3. Error messages are not formated(line-wrapped) by cmake's markup
so it's easier to check the output in tests.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
Extend existing target consistency checks for the two following cases.
1. Target does not match currently used toolchain
$ IDF_TARGET=esp32s2 idf.py reconfigure
$ idf.py -DIDF_TARGET=esp32c3 build
2. Target is ambiguous, because it's specified also as env. var.
IDF_TARGET=esp32s3 idf.py set-target esp32c2
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
The _guess_or_check_idf_target() function has sdkconfig and sdkconfig.defaults
file names hardcoded. Since config file names may be specified with SDKCONFIG
or SDKCONFIG_DEFAULTS cmake vars, directly in CMakeLists.txt or passed in with
the -D cmake option, they are not respected.
Problem is when SDKCONFIG or SDKCONFIG_DEFAULTS is set in
CMakeLists.txt. While idf can detect cmake vars passed through it
to cmake via the -D option, detecting SDKCONFIG and SDKCONFIG_DEFAULTS
vars settings in CMakeLists.txt would require to parse it. This seems
like error prone approach. Also if the vars defined by the -D option
are passed directly to cmake, not via idf, they will not be visible to idf.
It seems reasonable to move the logic into cmake, where we know the correct
SDKCONFIG and SDKCONFIG_DEFAULTS values. So the IDF_TARGET detection/guessing
is moved into targets.cmake, where the IDF_TARGET is actually set. The target
is guessed based on the following precendence.
1) $ENV{IDF_TARGET}
2) IDF_TARGET
3) SDKCONFIG
4) sdkconfig
5) SDKCONFIG_DEFAULTS if non-empty or
$ENV{SDKCONFIG_DEFAULTS} if non-empty or
sdkconfig.defaults
6) esp32
All config files referred in $ENV{SDKCONFIG_DEFAULTS} and SDKCONFIG_DEFAULTS
are searched, compared to the current behaviour. First target found in the
above chain is used.
The original _guess_or_check_idf_target() is renamed to _check_idf_target() and
used for the target consistency checks only.
The get_sdkconfig_filename() helper is now used to get the sdkconfig file
for consistency checks. It looks in SDKCONFIG specified with the -D
option and project_description.json.
With this change config full paths are reported in messages, so it's clear
e.g. from which config the target was guessed from or which config has
consistency problem. test_non_default_target.py was adjusted to this
change and also new test for testing the IDF_TARGET guessing was added.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
Get project's current sdkconfig file name. It looks in SDKCONFIG cmake var
defined by the -D option and project_description.json. If not found return
default sdkconfig.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
This parses cmakes cache vars defined on command line with -D options
into dictionary. It allows to simplify the check for new cache entries
and also can be re-used for other checks.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
1. Remove RTC_CLOCK_BBPLL_POWER_ON_WITH_USB Kconfig option
During sleep, BBPLL clock always gets disabled
esp_restart does not disable BBPLL clock, so that first stage bootloader log can be printed
2. Add a new Kconfig option PM_NO_AUTO_LS_ON_USJ_CONNECTED
When this option is selected, IDF will constantly monitor USB CDC port connection status.
As long as it gets connected to a HOST, automatic light-sleep will not happen.
Closes https://github.com/espressif/esp-idf/issues/8507
Pros:
- Using thread would face GIL issue and turns out very slow when running
with poor hardware.
Cons:
- Does not support windows anymore. For testing purpose, it's fine.
- 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.
- Added minor improvements to `panic` test app
* Replaced existing API to disable flash cache which did not disabled cache always
(`esp_flash_default_chip->os_func->start(esp_flash_default_chip->os_func_data)`)
with `spi_flash_enable_interrupts_caches_and_other_cpu`
* Included some required headers explicitly (`esp_memory_utils.h` and `esp_heap_caps.h`)
IDF_PYTHON_ENV_PATH is the path where the Python environment is created
and used. By default it is inside IDF_TOOLS_PATH. IDF_PYTHON_ENV_PATH
was exported by idf_tools.py but was not imported back. This fixes the
issue and ESP-IDF will honor the value of IDF_PYTHON_ENV_PATH.
Closes https://github.com/espressif/esp-idf/issues/10489
This adds a new outdated option, which only lists outdated
packages installed in IDF_TOOLS_PATH. It searches for the
latest installed tool version in the IDF_TOOLS_PATH/tools path and
compares it against the latest available version in the tools.json
file. If the latest version of a tool installed in IDF_TOOLS_PATH/tools
is smaller, it's reported as outdated. Nothing is reported if the tool
is up to date.
Two new tests are added. First just checks if nothing is reported in
case there is no update available. The second artificially generates
new tools.json file called tools.outdated.json and sets XTENSA_ESP32_ELF
version to 'zzzzzz'. It then checks if the XTENSA_ESP32_ELF tool
is reported as outdated by the 'zzzzzz' version.
Description of the new outdated option is addedd to docs as well.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
This moves one hint, which was hardcoded in debug_ext.py to
hints.yml and adds a new one when openocd process does not have
permissions to the USB JTAG/serial device.
Also hint replacing the original 'Please check JTAG connection!'
hardcoded message is added.
Suggested-by: Alexey Lapshin <alexey.lapshin@espressif.com>
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
The debug targets are currently not utilizing hints, because they
are not using RunTool() helper from tools.py to spawn sub-processes.
Adjusting debug targets to use RunTool() would require some significant
changes to debug targets and RunTool() as well. Since debug targets
are already storing their output in logs, we can use these and process
them for hints.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
cpu retention: add riscv core sleep critical and non-critical register layout structure definition
cpu retention: add assembly subroutine for cpu critical register backup and restore
cpu retention: add cpu core critical register context backup and restore support
cpu retention: add cpu core non-critical register context backup and restore support
cpu retention: add interrupt priority register context backup and restore support
cpu retention: add cache config register context backup and restore support
cpu retention: add plic interrupt register context backup and restore support
cpu retention: add clint interrupt register context backup and restore support
cpu retention: wait icache state idle before pmu enter sleep
Examples for zigbee are using custom license, which is not present
on the SPDX license list. This was discussed on !16205 and a decision
was made that the examples will be put on check-copyright's ignore list.
SPDX has LicenseRef-[idstring] identifier for such cases, so let's try
to use it. In this particular case the LicenseRef-Included is used to
express that the full license text is included in the source file.
Note that the LicenseRef-Included is not part of SPDX. It's just
something I used. No change is needed on the check-copyright side.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
Currently loading of esp32s3 ROM ELF symbols fails with
"Cannot access memory at address 0x3ff194ad". Let's perform
add-symbol-file after connection to the target.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
This commit fixes an issue where paths on Windows are case insensitive, for instance when setting the build folder its name would be converted to lowercase.
The culprit is our realpath() function, that was calling os.path.normcase() internally, since we are removing that call it makes sense to just remove the function entirely and call os.path.realpath() wherever necessary.
Closes https://github.com/espressif/esp-idf/issues/10282
The main idf.py process has a handler for SIGINT, which actually just
ignores it. The get_default_serial_port() function is called within the
idf.py context to detect port for several tools(monitor,flash) and it's
not possible to terminate it because of this. Let's ignore SIGINT only
while running idf_monitor, which uses it to spawn gdb.
Fixes: c6e3eb0922 ("idf.py.exe changes to handle Ctrl+C in correct way. H..")
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
This commit fixes two issues:
1. Part of the header containing annotations for curr, reference and diff values for archive diffs wasn't formatted correctly
2. Only one third of the values in the table were displayed because of the wrong line format
Since the introduction of PCAddressMatcher, the executable produced
by the build system is passed to elftools.elf.elffile.ELFFile.
However on macOS, native executables are not ELF files, so the
ELFFile class raises a rather unhelpful AssertionError exception.
Given that the rest of the idf_monitor.py doesn't have assumptions
that the "elf_file" argument is an ELF file (rather than just an
executable), check if the file is a real ELF file inside
PCAddressMatcher.
When multiple targets are specified, e.g. idf.py flash monitor, the
automatic port detection is performed twice. Keep the port value in
args.port and avoid multiple calls to get_default_serial_port().
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
This commit migrates the esp_pm unit tests from the legacy unit test to a
stand alone test app. The following CI configurations are provided
- Default: Automatic light sleep with mostly default configurations
- Options: Enables all of the optional esp_pm features
- Limits: Limit tests esp_pm
Set CONFIG_NEWLIB_TIME_SYSCALL_USE_HRT to enable to force CONFIG_ESP_TIME_FUNCS_USE_RTC_TIMER to disable
and hence prevent the following tests from being executed:
- Timestamp after abort is correct in case RTC & High-res timer have + big error
- Timestamp after restart is correct in case RTC & High-res timer have + big error
- Timestamp after restart is correct in case RTC & High-res timer have - big error
This commit removes the dependency on portUSING_MPU_WRAPPERS on the Xtensa port
of IDF FreeRTOS. This dependency was added due to a hack implemented in the
upstream port that required the usage of the "xMPUSettings" member of the TCB.
The "xMPUSettings" would be used as a pointer to the task's coprocessor save
area on the stack, even though FreeRTOS MPU support was not available.
The hack has now been removed, and the CPSA pointer is now calculated using
a combination of constant offsets values and the pxEndOfStack member of the
TCB.
Note: This impelemtation was copied from the Xtensa port of Amazon SMP FreeRTOS.
Previously get_idf_build_env didn't include the default environment
(os.environ) in its output, so the environment only contained the
variables returned by "idf_tools.py export".
If PATH already contains all the right paths, "idf_tools.py export"
doesn't return the PATH variable.
Therefore the environment returned by get_idf_build_env was usually
incomplete. Fix by combining the output of "idf_tools.py export" with
os.environ.
esp_netif various fixes: dependency cleanup, default flags, CI rules
Closes IDF-5550, IDFGH-7023, IDF-1261, and IDF-2155
See merge request espressif/esp-idf!20301
It is required to define a mandatory dependency on lwip, so we
introduced esp_netif_stack component and made it require lwip, instead
of directly depending on lwip.
This enables building w-out lwip and support other TCP/IP stacks.
This commit refactors the OS startup functions as follows:
- Moved the OS/app startup functions listed below to "app_startup.c". Their
implementations are now common to all ports (RISC-V and Xtensa) of all
FreeRTOS implementations (IDF and Amazon SMP).
- esp_startup_start_app()
- esp_startup_start_app_other_cores()
- Removed esp_startup_start_app_common() as app startup functions are now
already common to all ports.
- Added extra logs to "main_task" to help with user debugging
Note: Increased startup delay on "unity_task". The "unity_run_menu()" is non
blocking, thus if the main task or other startup tasks have not been freed
by the time "unity_run_menu()" is run, those tasks will be freed the next time
"unity_task" blocks. This could cause some tests to have a memory leak, thus
the "unity_task" startup delay has increased.
This fixes an attempted fix for diram size calculation where it was counted twice, however the fix did not account for cases where iram was not fully filled with cache and therefore was of non 0 size.
Now the calculation should be correct regardless of the cache size.
Closes https://github.com/espressif/esp-idf/issues/9960
