dl.espressif.com is now using the same root certificate as github.com.
This commit replaces the previously-used ISRG X1 root certificate
with the DigiCert Root CA certificate.
As a result, even if the certificates are not installed (as it happens
on macOS with python.org installers, if the user forgets to run
'Install Certificates.command'), the download is successful.
Related to https://github.com/espressif/esp-idf/issues/4081
This fixes the issue with build output not being colorized on Windows,
while the hints messages are colorized.
The issue occurred because sys.stdout and sys.stderr get overridden
by colorama.init() at runtime, but the default argument
output_stream=sys.stdout holds the reference to the"original"
sys.stdout.
colorama.init() (which, by the way, gets called via a curious chain
of imports, via idf_component_tools.manifest and tqdm package)
overrides standard streams, on Windows only. The overridden streams
contain logic to convert ANSI color codes into Windows Console API
calls to colorize the text.
Since read_and_write_stream function used the default value of
output_stream evaluated at module loading time, it was using the
original sys.stdout, not the one overridden by colorama.
One extra note is that while this does fix the coloring issue, the
solution is a bit fragile, as it relies on one of the following
(on Windows):
- colorama.init() is called (this can change if idf-component-manager
stops importing tqdm)
- Sufficiently new version of Windows 10 is used, and ANSI color codes
support is enabled in the Registry.
update gpio_sig at `spics_out` array in each spi_periph.c of chips later than s2
then `spi_bus_add_device` can correctly distribute gpio_signals for cs_signal
Closes https://github.com/espressif/esp-idf/issues/8876
In previous gpio default isr, interrupt status bits get cleared at the exit of the isr.
However, for edge-triggered interrupt type, the interrupt status bit should be cleared before entering the per-pin handlers to avoid any potential interrupt lost.
Closes https://github.com/espressif/esp-idf/pull/6853
This commit fixes build issue because of function `bootloader_common_reset_rtc_retain_mem`
getting inlined with compiler optimization level set to `PERF` (-O2).
Build failure log:
-----------------
In function 'bootloader_common_reset_rtc_retain_mem',
inlined from 'bootloader_common_update_rtc_retain_mem' at /h/esp-idf/components/bootloader_support/src/bootloader_common_loader.c:183:13:
/h/esp-idf/components/bootloader_support/src/bootloader_common_loader.c:159:5: error: 'memset' writing 16 bytes into a region of size 0 overflows the destination [-Werror=stringop-overflow=]
159 | memset(rtc_retain_mem, 0, sizeof(rtc_retain_mem_t));
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- primary reason: 4.6.2 fixes errors if the user's home directory contains a space
- alternative fix: the CCACHE_DIR env var can be set to something without a space in it, or set to TMP which properly escapes the home dir name
- there may be other issues with spaces in filenames on builds in other parts of ESP-IDF, see https://github.com/espressif/esp-idf/issues/8364 for more info
tested locally on windows only, use at your own risk
Closes https://github.com/espressif/esp-idf/pull/9656
This commit fixes gpio_hold_en(pin) function for ESP32, where after wakeup from deep sleep, the pin gets reset to default state and stop holding the pin level.
On the build runners, the installation frequently takes around 150
seconds, which is above the current timeout. This change increases
the timeout.
Closes IDFCI-1436
libpython2.7 was added to the container to allow running GDB built
with Python 2.7 support and distributed as part of the cross-compiler
toolchain.
Now that we have a new release of GDB which works with Python 3.x,
the GDB shipped with the cross-compiler is no longer used. Removing
libpython2.7 should reduce the image size.
This reverts commit be0372b1db36d2cb7d94e4baafb1772ea6e38452.
`__COMPONENT_TARGETS` is evaluated very early when components and
component directories are added to the build, which means that all
components (including the ones which are in EXCLUDE_COMPONENTS) have
a build system target defined. The component manager was given the
list of all known components (derived from the list of targets), not
the list of components after EXCLUDE_COMPONENTS were processed.
Because of that, EXCLUDE_COMPONENTS didn't effectively exclude the
component from the consideration of the component manager.
