Current implementation implicitly forces the developer to use global variables
to enter its context during the command invocation, this change enables each
module to register a context for command to find without the need to manage
global variables.
No API breakage.
Fields added:
esp_console_cmd_t::func_w_context - (*)(int argc, char **argv, void *context)
Functions added:
esp_err_t esp_console_cmd_set_context(const char *cmd, void *context)
Usage:
esp_console_cmd_register(&cmd));
esp_console_cmd_set_context(cmd.command, (void *)"context"));
Signed-off-by: Alon Bar-Lev <alon.barlev@gmail.com>
The size of partition of type APP should be multiple of 4 KB. Partition
generation tool now make this as a mandatory requirement. This is
minimum flash erase size. If the size of the APP type partition is not
aligned to 4 KB then the last erase operation could go beyond the allocated
partition and hence may fail. This issue would only be observed when the
firmware size grows very close to the allocated partition size, and hence
causing the OTA update to fail.
For already deployed devices on-field with the size of APP partition not
aligned to flash sector boundary, it is best to ensure that firmware
size always remains within the lower 4 KB boundary of the total
allocated space. While migrating to ESP-IDF 5.3 release, partition table
for an existing project can be adjusted accordingly for the build to
succeed.
Found during discussion in https://github.com/espressif/esp-idf/pull/12460
docs: Provide Chinese translation for bootloader_image_format, log, random, and internal-unstable.rst
Closes DOC-6419
See merge request espressif/esp-idf!26224
The fatfsparse.py script was too strict in parsing the FAT boot sector, causing it to fail in
certain cases. This commit fixes the issue by making the parsing less strict and allowing for more
flexibility in the boot sector format.
This change improves the reliability and compatibility of the fatfsparse.py script, ensuring that it
can correctly parse a wider range of FAT boot sectors.
Docs updated
This commit enables the standad VERSION argument for the project() macro
in ESP-IDF. The VERSION argument is compilant with the requirements of
cmake 3.16. This commit also adds new test cases for verifying the
validity of the version argument.
Merges https://github.com/espressif/esp-idf/pull/12461
Co-authored-by: Sudeep Mohanty <sudeep.mohanty@espressif.com>
Previously, documentation sections that were only meant for multicore ESP
targets would use tags that depend on CONFIG_FREERTOS_UNICORE or
CONFIG_ESP_SYSTEM_SINGLE_CORE_MODE. This is not ideal as project configuration
can be changed by the user.
This commit updates those tags to use SOC_HP_CPU_HAS_MULTIPLE_CORES which is
always defined in multicore targets regardless of project configuration.
- This change will introduce a breaking change for SoCs with the HMAC
peripheral. Turning on flash encryption will no longer enable NVS
encryption automatically.
Closes https://github.com/espressif/esp-idf/issues/12549
This extension allows running programs in QEMU similar to running
them on a real chip:
- 'idf.py qemu' — builds and runs the program in QEMU. User gets
a QEMU instance launched, and can work with it as a normal QEMU
instance.
- 'idf.py qemu monitor' — same, but QEMU is launched in the
background, and idf_monitor runs in the foreground, showing QEMU
output. Compared to only running 'idf.py qemu' this enables, for
example, automatic backtrace decoding.
- 'idf.py qemu gdb' — launches QEMU in the background and opens an
interactive GDB prompt, connecting it to QEMU.
- 'idf.py qemu --gdb monitor' and 'idf.py gdb' in another shell:
launches QEMU in the background, keeps it suspended until GDB is
connected, and opens idf_monitor. GDB can be used in another shell
to debug the application.
Many places in the ESP_SYSTEM are using CONFIG_FREERTOS_UNICORE instead of CONFIG_ESP_SYSTEM_SINGLE_CORE_MODE (GitHub PR)
Closes IDFGH-11333
See merge request espressif/esp-idf!27435
