Simple flash read command is not supported if Secure DL mode is enabled on the target.
Remove reference of this from the relevant docs part.
Related: https://github.com/espressif/esptool/issues/810
Related: ESPTOOL-567
Closes IDF-6468
This commit removes the GPL license text from various FreeRTOS port files as it
no longer matches the licensing of FreeRTOS v10.4.3 which is distributed under
the MIT license.
When a public header contains _Static_assert or static_assert, check_public_headers.py script will detect it and report it as an issue.
Indeed, public headers shall now use ESP_STATIC_ASSERT.
I'm including <hal/uart_ll.h> in my C++ application because I need to
bypass the uart driver. The inline functions in the header file fail to
compile as C++.
All of the enums need explicit casts for conversion to/from integers.
Merges https://github.com/espressif/esp-idf/pull/10106
1.Bugfix for clear bss info when wifi stop
2.Bugfix for add clear ap list interface
3.Modify wifi scan return value.
4.Change the log level of some logs to avoid misunderstanding.
5.Fix connect fail return wrong error code issue.
6.Fix WAPI issue on gtk compability and referrence to broadcast arp pkts.
7.Support WiFi tx fragment in the crypto mode of gcmp.
8.Fix tx fragment issue that pn code is less than msdu after pn code add two for tx fragment.
9.Fixed some issues on Soft-AP power save.
10.fix invalid child issue
11.fix WIFI_EVENT_AP_STADISCONNECTED event error
12.Fix SoftAP memory leak issue.
13.Fixed sta get ap info does not return connected ssid issue.
14.Fix SoftAP recv ps-poll not update inactive timer issue.
1. Adding check for ies in match security
2. Set AP rsnxe while connecting to a AP
3. Restores station status to connected when no other AP is found for roam
4. Add config option for AP retry count
5. Fix unprotected SA Query issue
Bluetooth low power related logic and regs have separate power domain from MAC and BB,
and do not power down during light sleep. If reset when power up MAC and BB in sleep
flow, it may destroy the state of bt low power part.
User's custom data are not taken into account during the CRC calculation anymore.
Which means taht the retained mem structure is not systematically erased
on each reboot anymore.
A missing flush in the serial reader implementation for
Linux target was causing input to idf.py monitor to not
be forwarded to the application. This is fixed now.
By default, disabled the BLE Encrpyption requirement for provisioning characteristic.
With this flag enabled, when remote attempts to read and if the ACL link is not encrypted,
ESP device will return Insufficient Authentication. It is remote device responsibility to go
for link encryption which may result in pairing.
Some devices do not proceed for any pairing and just show failure pop-up. Also, user needs
to remove bonding on remote phone manually and then try again. This is causing bad user experience.
End user can enable it as per their use case.
- Added config to disable scan backoff
- Fixed llm_scan.c assert at line 1485 during controller deinit if duplicate scan is not stopped
- Call pll track in controller task
spi_flash: Building a framework to enable HPM when flash works under high speed mode, take GD as an example.(backport v4.4)
See merge request espressif/esp-idf!17758
bluetooth: use non-blocking coexistence callback functions so that Wi-Fi task is not blocked by Bluetooth(backport v4.4)
See merge request espressif/esp-idf!20779
Fix issue with single bus clear counter but two I2C buses (I2C0, I2C1). The previously implemented single (static) counter would impact the second bus either if one bus has counter expiry.
Merges https://github.com/espressif/esp-idf/pull/7144
This commit adds a simple flag/check in the USB Host Library that prevents
users from submitting a transfer that is already inflight.
- A transfer is considered inflight as soon as it is submitted by calling
usb_host_transfer_submit() or usb_host_transfer_submit_control()
- An inflight transfer remains inflight up until right before its callback
is called by one of the USB Host Library handler functions.
Closes https://github.com/espressif/esp-idf/issues/8748
Non-visible configs would previously not appear in the deprecated section of the sdkconfig.h,
but non-visable configs are used in IDF (and user code) and should therefor be present.
Previous the console doc is moved from api-guide to api-reference, which
broken the URL as well, this commit added a redirect link to ensure the
old URL can still work.
The calculation of fl index max is changed to always be the smallest
number that includes the size of the registered memory.
The control_construct() function now checks for minimum size as the control structure
parameters are calculated.
There is no longer a minimum configuration for fl index max so the tlsf_config
enum is striped down to remove unecessary compile time values.
the tlsf_size() function will fail if no tlsf pointer is passed as parameter since there
is no way to calculate a default tlsf size anymore.
bitfields are now used in control_t when possible which reduces the size of the structure
from 56 bytes to 36 bytes.
light sleep wakeup flag is true to indicate the most recent successful wakeup from light sleep,
which means the most recent light sleep occurred successfully and then wakes up by wakeup source
In case of `esp_http_client_read` based workflow, we cache data that is received
during fetch header stage. In case, there is URL redirection and we have to close
the connection on URL, port change then we must discard earlier cached data.
Closes AUD-4158
This commit adds the missing ESP_PLATFORM preprocessor directive to
static data structures to wrap the extra variable added for SMP locks.
Closes https://github.com/espressif/esp-idf/issues/9785
This commit fixes a bug where if an unpinned task is interrupted by a level 1
ISR that users the FPU, the FPU usage will cause the interrupted task to
become pinned to the current core.
Note: This bug was already fixed in SMP FreeRTOS in commit
d6936177. This commit simply backports the fix to IDF FreeRTOS.
Similar to the fix in gpio lower layers, USB Serial JTAG pad should be disabled when the DM and DP pins want to be used as rtcio pins.
(cherry picked from commit de0401047c)
GDB now is standalone tool separated from toolchain due to frequent updates.
Added installation tests for the new tool.
Coredump tests are changed because they were wrong, see explanation:
esp32 objdump:
40084290 <esp_crosscore_int_send_yield>:
......
/builds/espressif/esp-idf/components/esp_system/crosscore_int.c:145
4008429c: 000090 retw
With previous GDB backtrace was:
#0 0x4008429c in esp_crosscore_int_send_yield (core_id=0) at /builds/espressif/esp-idf/components/esp_system/crosscore_int.c:144
This commit fixes the backtrace with the right line number:
#0 0x4008429c in esp_crosscore_int_send_yield (core_id=0) at /builds/espressif/esp-idf/components/esp_system/crosscore_int.c:145
Other tests changes have the same cause of fixing.
Closes https://github.com/espressif/esp-idf/issues/6334
For project with reduced component list, secure boot signing key
path was not getting correctly. This change sets the secure boot
signing key path explicitly based on the relevant config option.
Closes https://github.com/espressif/esp-idf/issues/9578
Close IDFGH-8075
1. Deinit does not return ESP_ERR_WIFI_NOT_INIT if the wifi driver is no longer initialized.
2. Fix get wrong channel value use esp_wifi_get_config.
3. Fix bug of missing unlock when wifi stop.
4. Fix annotation error of api esp_wifi_connect.
In previous transmission(s), the TX_DONE interrupt raw bit may be raised, but never been cleared.
TX_DONE interrrupt status bit should be cleared before enabling it to check the new transmission.
Introduced in 4e09d147b11ed8a094b5858642c9f60d658ef656
Internally, disable usb serial jtag DP pin's pullup when calling gpio_ll_pullup_dis and rtcio_ll_pullup_disable
At usb serial jtag setup/install, re-enable DP pin's pullup
Closes https://github.com/espressif/esp-idf/issues/9495
ledc_ls_timer_update is required only when CLK_DIV and DUTY_RES bits are changed.
Calling ledc_timer_rst while re-configure PWM frequency through ledc_set_freq can cause glitch in the signal
esp_light_sleep_start() will stall the other CPU via esp_ipc_isr_stall_other_cpu(). After stalling the other CPU,
will call esp_clk_... API which themselves take locks. If the other stalled CPU is holding those locks, this will
result in a deadlock.
This commit adds a workaround calling esp_clk_private_lock() to take the lock before stalling the other CPU.
esp_clk used to be protected using _lock_t (i.e., a FreeRTOS Mutex). However, esp_clk API is current called from
from critical sections, thus mutex should not be used (as they can be blocking).
This commit updates esp_clk to use spinlocks for critical sections instead.
Note: Added a small fix to exclude esp_clk.c from bootloader builds in the
legacy build system (this is already the case in CMake).
define: lock_bits = (lock->status & LOCK_MASK) >> LOCK_SHIFT; This `lock_bits` is the Bit 29-20 of the lock->status
1. spi_hdl_1:
acquire_end_core():
uint32_t status = lock_status_clear(lock, dev_handle->mask & LOCK_MASK);
Becuase this is the first `spi_hdl_1`, so after this , lock_bits == 0`b0. status == 0
2. spi_hdl_2:
acquire_core:
uint32_t status = lock_status_fetch_set(lock, dev_handle->mask & LOCK_MASK);
Then here status is 0`b0, but lock_bits == 0`b10. Because this is the `spi_hdl_2`
3. spi_hdl_2:
`acquire_core` return true, because status == 0. `spi_bus_lock_acquire_start(spi_hdl_2)` then won't block.
4. spi_hdl_2:
spi_device_polling_end(spi_hdl_2).
5. spi_hdl_1:
acquire_end_core:
status is 0, so it cleas the lock->acquiring_dev
6. spi_hdl_2:
spi_device_polling_end:
assert(handle == get_acquiring_dev(host)); Fail
Closes https://github.com/espressif/esp-idf/issues/8179
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
`__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.
Due to unit test, we can't specify runners, for adc related tests.
Whereas adc tests are easily influenced by board hw condition, e.g.
pullup/down value.
This commit increases the thresh to 200mV.
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
Fixed calling esp_ble_get_cur_sendable_packets_num() sometimes crashes when bluetooth is disconnecting (backport v4.4)
See merge request espressif/esp-idf!20042
'idf_tools.py add-version' has new options:
--override Override tool versions with new data
--checksum-file URL or path to local file with checksum/size for artifacts
Usage e.g.:
CHECKSUM_URL=https://github.com/espressif/crosstool-NG/releases/download/esp-2021r2/crosstool-NG-esp-2021r2-checksum.sha256
idf_tools.py add-version --tool xtensa-esp32-elf --version esp-2021r2 --override --checksum-file $CHECKSUM_URL
Positional argument 'files' moved to optional argument '--artifact-file'
Add tests for add-version logic
- Fixed the performance issue of BLE sync scan in coexistence scenario when PLL track is enabledFixed the usage of PLL track related baseband IRQs
- Fixed connect failed due to error sync found signal
- Fixed BLE disconnect failed due to terminate_ind have sent but no ACK is received
- Added ADV mode error check in ADV rx isr handler function
- Fixed BLE RAL_UNDERRUN and TX_CRYPT_ERR assert
- Disable scan continue
- Fixed scan forever if scan continue is disable
bt:Fixed deadlock due to wrong parameter when calling btc_transfer_context() after calling esp_bluedroid_disable()(v4.4)
See merge request espressif/esp-idf!19951
If a windowoverflow8 happened after changing the SP, the exception handler would look for
the extra save area by looking at the previous frame's SP. This SP would be a garbage value
and could cause the windowoverflow exception to write to invalid memory ares.
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.
This commit extends the heap test set by adding a test to check corruption
detection in free memory block.
For each byte of the free block memory, the test changes the value of the byte,
call multi_heap_check(), make sure that the function returns 'corruption detected'
only when comprehensive poisoning is set, restore the good value of the byte, calls
multi_heap_check() again and make sure that it returns 'OK'.
Add a call to tlsf_check_hook() in tlsf_check() that calls
multi_heap_internal_check_block_poisoning() and check the memory
of every free blocks when heap poisoning is active.
bt:No need to use local copy of btc_msg_t in btc_transfer_context, create it on heap and pass to osi_thread_post()(v4.4)
See merge request espressif/esp-idf!19692
sizeof(time_t) was previously switched from 4 to 8, ROM functions that use
time_t or dependent types (such as "struct stat") are no longer called due as
they still treat sizeof(time_t) as 4 (see commit
24c20d18).
However, there is a ROM callpath that was left out. If putchar is the first
stdio print related call, the call path will result in cantwrite() ->
__swsetup_r() -> __smakebuf_r() -> __swhatbuf_r() using the ROM "struct stat"
(where sizeof(time_t)==4).
Instead of removing all printf related ROM newlib functions (which will result
in increased binary size), this commit adds a workaround to setup the stdio
files before any print related calls occur.
This results in cantwrite() always returning false, thus the callpath described
above never being reached.
Closes https://github.com/espressif/esp-idf/issues/9269
Closes https://github.com/espressif/esp-idf/issues/7207
The description of how the xTaskGenericNotifyWait parameter is handled in the
xTaskGenericNotifyWait() function was inaccurate.
In this commit, the description was updated to match the implementation of xTaskGenericNotifyWait().
Adding prop and lit sections to the ELF will let the debugger and the disassembler
have more info about data bytes present in the middle of the Xtensa
instructions, usually used for padding.
Due to the lack of synchronized connections, the hf_client can not create audio_connection to
hf_ag. Set default number of synchronized connection to 1.
Closes https://github.com/espressif/esp-idf/issues/9537
xSemaphoreGive won't be executed in configASSERT and semaphore will stay locked if NDEBUG (idf v5) or CONFIG_FREERTOS_ASSERT_DISABLE (idf v3, v4) are defined.
The event group unit tests would previously use a single call bit (the
"BIT_CALL" macro) to unblock all the test tasks. However, if one or more tasks
were delayed in calling xEventGroupWaitBits(), the other tasks would clear the
test bits, leading to the test deadlocking.
This commit updates the bits used so that each task gets their own CALL and
RESPONSE bits.
There should be only one workqueue for BTU task. The queue length for the second workqueue of BTU can be uninitialized and caused memory overflow and corruption.
Closes https://github.com/espressif/esp-idf/issues/9507
For secure boot enabled cases, bootloader and firmware images have signature
appended and size is variable based on scheme being used. This appended data
must be considered while verifying image length against allocated partition
size to avoid any possibilities of going beyond reserved size.
Closes IDF-5617
Functions used for burning this efuse would log, but at this point
esp_log is not initialized. Moved to a later point in the startup process.
Closes https://github.com/espressif/esp-idf/issues/9457
Don't call heap_caps_alloc_failed() for malloc(0) and calloc(0), because it is not an error.
Improve handling of malloc(0) and calloc(0).
Merges https://github.com/espressif/esp-idf/pull/9517
heap_caps_*_prefer functions will now only call heaps_caps_alloc_failed
callback if all attempts to allocation memory fail (and not after each attempt
anymore).
* Closes https://github.com/espressif/esp-idf/issues/9086
esp-ringbuf funtion placement is now controlled by its own configs:
CONFIG_RINGBUF_PLACE_FUNCTIONS_INTO_FLASH and CONFIG_RINGBUF_PLACE_ISR_FUNCTIONS_INTO_FLASH
Closes https://github.com/espressif/esp-idf/issues/9198
some fixes after modifications:
1. removed the use of waiting_command_t
2. fix assert for HCI write_eir command
3. fixed the crash upon handling command status event when trying to free to the HCI command buffer
4. fixed the issue in transmitting HCI vendor specific commands
5. fixed the lost command complete callbacks for HCI commands LE_RAND and LE_ENCRYPT
1. bluedroid: use standard function pointer define.
2. blufi: Change ESP_BD_ADDR_LEN into ESP_BLUFI_BD_ADDR_LEN
3. doc/sphinx_known_warnings: Remove fixed parts.
1. When setting compilier into -O2 optimization, build for classic bt demo will get wrong
2. Fix a memcpy bug that maybe get memory truncated
Closes https://github.com/espressif/esp-idf/issues/9398
Currently, we pull up cs io for spi flash/ram to reduce current leakage during
light sleep. But some kind of spi flash/ram chip need all io pull up. Otherwise,
current leakage will still exist.
Since cpu retention dma use rc fast as clk source, so rc_fast_digi
will be enabled when we config to pd cpu. And cpu retention does not
need rc fast keep on during light sleep. So, if we use rc_fast_digi
to determine whether rc fast can be powered down, then cpu and and
rc fast cannot pd at the same time.
As heap block may be allocated into multiple non-continuous chunks, to
reserve enough memory for dma/internal usage, we do the malloc in the
step of max available block.
Some users have requested this feature.
In order to avoid complete refactoring or introducing more code complexity, a design choice to create temporary files without blank lines is made.
Additionally, an extension check is added and there are multiple smaller code style and structure improvements.
Closes https://github.com/espressif/esp-idf/issues/8421
When working in continuous mode, hardware will continuously trigger
ADC to do conversions. On esp32s2, 2 bytes will be generated per
conversion. Prior to this commit, driver assumes 4 bytes per conversion
(on s2). This commit fixed this issue.
Prior to this change, esp32s3 ADC continuous mode output resolution is 13 bits.
This commit correct the `adc_digi_output_data_t` on esp32s3. Correct
output bits should be 12 bits. Corresponding definition in `soc_caps.h`
is also updated.
Was: Backtrace: N:M N:M N:M ...
Now: Backtrace:N:MN:M N:M ...
The problem with the new format is that it is hard to parse and
breaks the parser that is used by PlatformIO. The old format
is much more reasonable. I do not see how the pattern in IDFDUT.py
can work with the new format, due to the missing space after the :
The "FreeRTOS Event Groups" main task will only wait a single tick for the created
tasks to set their response bits. This short delay may not be sufficent if the tick
frequency is high.
This commit updates the test so that
- the main task waits indefinitely for all the response bits to be set.
- created tasks are cleand up by the main task
FreeRTOS synchronization primitives (e.g., queues, eventgroups) use various event lists (i.e., task lists) to track what
tasks are blocked on a current primitive. Usually these event lists are accessed via one of the event lists functions
(such as vTask[PlaceOn|RemoveFrom]UnorderedEventList()), which in turn ensure that the global task list spinlock
(xTaskQueueMutex) is taken when accessing these lists.
However, some functions in event_groups.c manually traverse their event lists. Thus if a tick interrupt occurs on
another core during traversal and that tick interrupt unblocks a task on the event list being traversed, the event list
will be corrupted.
This commit modifies the following event_groups.c functions so that they take the global task list lock before
traversing their event list.
- xEventGroupSetBits()
- vEventGroupDelete()
1. Rename MACROs SYSTEM_WIFI_RST_EN register bit fields to be more recognizable
2. reset Bluetooth baseband and MAC bits to fix the issue of task watchdog triggered during controller initialization due to invalid hardware state
Idle tick hook that indicates completion of scheduler init must be launched
on other core than the one where main task runs. Earlier it was assumed that
main task shall always run on PRO cpu but that behavior can be changed with
ESP_MAIN_TASK_AFFINITY_CPU1 and hence this fix.
Closes https://github.com/espressif/esp-idf/issues/9247
Closes IDFGH-7705
The Xtensa FreeRTOS port does not save the threadptr register when
doing a voluntary yield. This can result in a crash when multiple
tasks used the threadptr register and call "taskYIELD()".
This commit adds the threadptr register to the solicited stack frame.
The change fixes thread-local-storage size by removing .srodata section
from it. It initially was included in TLS section by mistake.
The issue was found when stack size increased after building applications
with GCC-11.1 compiler. Stack size became bigger because some new data
appeared in .srodata. See more details here:
https://github.com/gcc-mirror/gcc/commit/adce62f53d8ad00e8110a6a2de7962d7a850de16
1.Update wifi doc for espnow/LR/fix rate/disable 11b/multiple antennas
2.Optimization example of wifi station
3.Optimize the null pointer judgment of eb
4.Bugfix for close sniffer mode when wifi stop
5.Fix deep sleep can't reconnect to ap when pmf enable.
6.Fix some ap will ignore auth when rx deauth for a while.
7.Fixed espnow recv unencrypted packets issue
8.Fix not update phy according to country code.
9.Update regdomain max channel according to country info from nvs and or AP.
10.Channel 14 is allowed only 11b mode.
11.Remove csa when switch channel from/to 14 channel.
12.Update phy mode nvs when softap channel from 14 to other.
13.Fix the bug that check whether channel parameter is valid.
The following functions are only defined when CONFIG_PM_ENABLE is defined:
- wifi_apb80m_request()
- wifi_apb80m_release()
This commit makes their linker script mapping statements also dependent on CONFIG_PM_ENABLE
thus fixing some linker errors when CONFIG_PM_ENABLE is disabled.
This commit enables ULP FSM support for esp32s3 and updates ULP FSM code
flow for other chips.
It adds C Macro support for the ULP FSM instruction set on esp32s2 and
esp32s3.
The unit tests are also updated to test ULP FSM on ep32s2 and esp32s3.
The previously used splits between memory allocated for ROM code,
2nd stage bootloader and the app were somewhat safe and conservative.
This resulted in some space being unavailable for static allocation
in the app.
This commit increases the space available for static allocation to the
maximum possible amount.
1. Some of the ROM code static allocation is only used in UART/USB/SPI
download modes. This region ("shared buffers") has been placed at
the lower end of ROM memory area, to be reusable in flash boot
mode. The 2nd stage bootloader linker script is modified to "pack"
all sections exactly up to the end but with roughly 8K margin between
startup stacks.
2. Instead of calculating the sections placement and hardcoding the
addresses in the LD script again, rewrite it to calculate the
start address of each memory region automatically based on the
logic above.
3. Adjust the app memory layout (SRAM_IRAM_END) accordingly,
increasing the space available for static allocation.
Overall these changes increase the space available for static
allocation by about 78kB.
The downside of these changes is that the 2nd stage bootloader .data
segment is now directly adjacent to the startup stack on the PRO CPU.
Previously, there was effectively about 78kB of extra stack space for
the PRO CPU, before the stack would run into the data segment.
On riscv core, core cycle counter counts the clock cycles only when core is active (not sleeping).
In spi_slave/sender example, it uses ccount (core cycle counter) to do a simple debounce.
Therefore, when using spi_slave/sender and spi_slave/receiver, program will be stuck.
This commit fix this issue by using esp_timer
Defining CMake variables from the command-line or from another CMake project,
such as `-DCMAKE_C_FLAGS= -DCMAKE_CXX_FLAGS=`, caused a link failure as ESP
CMake was unable to set its proper compilation flags.
Additional CMake compiler flags can now be provided by another project.
* Closes https://github.com/espressif/esp-idf/issues/7507
add: private include header
add: macro encapsulation for assertion or error check
add: ESP_FAIL return code documentation in public headers
change: replaced all assertions by NVS_ASSERT_OR_RETURN macro
change: few internal function return values from void to esp_err_t
change: ESP_ERR_NVS_VALUE_TOO_LONG macro comment
This fixes the issue where multiline strings and strings with delimiters inside the nvs input csv file were incorrectly parsed, and adds back the ability to add comment lines anywhere in the CSV file.
The issue stems from the move away from the python built in csv module to manual parsing, which was made after moving away from using the csv module to parse mfg data.
This reverts back to using the csv module for parsing and writing csv data in both mfg_gen and nvs_partition_gen, fixes the original issue in mfg_gen and improves code quality which makes the code more readable and maintainable.
Closes https://github.com/espressif/esp-idf/issues/7175
Refactor examples to build with MBEDTLS_CERTIFICATE_BUNDLE disabled. Only examples
that can work with certificate bundle disabled have been modified here.
Use local python server to test client session tickets
Update example test to test the client session tickets
Check for minimum heap info in the example test.
mktime function uses tm_isdst member as an indicator whether the time
stamp is expected to be in daylight saving time (1) or not (0).
FAT filesystem uses local time as mtime, so no information about DST
is available from the filesystem.
According to mktime documentation, tm_isdst can be set to -1, in which
case the C library will try to determine if DST was or wasn't in
effect at that time, and will set UTC time accordingly.
Note that the conversion from UTC to local time and then back to UTC
(time_t -> localtime_r -> FAT timestamp -> mktime -> time_t) does not
always recover the same UTC time. In particular, the local time in the
hour before DST comes into effect can be interpreted as "before DST"
or "after DST", which would correspond to different UTC values. In
this case which option the C library chooses is undefined.
Closes https://github.com/espressif/esp-idf/issues/9039
Originally reported in https://github.com/espressif/arduino-esp32/issues/6786
`vTaskGetSnapshot` is being used in coredump module to collect diagnostic information.
It is possible that input arguments are invalid and `assert` in this situation is not
correct.
This commit modifies API signature to return pdTRUE in case of success, and pdFALSE
otherwise. Caller can verify return value and then take appropriate decision.
Previously linenoiseProbe would accept any 4 byte response, even one
that isn't expected. This adds a check that the first byte of the
response is ESC.
Suggested in https://github.com/espressif/esp-idf/issues/8839.
Replaces the previously used Docker Hub autobuild infrastructure.
This allows for more flexible configuration of the build process,
at the expense of some extra maintenance of CI workflow files
required.
These two arguments can be used to reduce the size of the Docker
image:
- Setting IDF_CLONE_SHALLOW enables shallow cloning.
- Setting IDF_INSTALL_TARGETS to the comma separated list of targets
results in toolchains being installed only for these targets.
Purpose:
This will allow for easily automating periodic updates to
"cacrt_all.pem" file.
Note:
For now newly created "cacrt_local.pem" contains single "DST Root CA X3"
which we are keeping to manage compatibility with endpoints like
"howsmyssl.com". Please note this Root CA is expired and is not part of
Mozilla’s NSS root certificate store.
This commit fixes the systimer_counter_value_t by adding a resreved field so that the
type fills 64-bits.
Without the reserved field, when compiling with -O0 optimization, the unoccupied high
bits would not be initalized by the compiler, leading to systimer_hal_get_counter_value()
returning a garbage value.
if COAP_CONSTRAINED_STACK is defined (is for esp-idf), the mutexes set up
to protect the critical sections were not working as expected and were just
dummy entries.
Use the pthread_ version of the mutex instead by defining HAVE_PTHREAD_H
and HAVE_PTHREAD_MUTEX_LOCK.
Since ulp wakeup signal are connected to ulp int raw(except esp32), we
need to clear ulp int raw before sleep when ulp wakeup enabled. Otherwise,
if the ulp int raw is already set, chip will not sleep properly.
Closes https://github.com/espressif/esp-idf/issues/6229
This fixes a potential race condition in select() if both a socket-fd
and non-socket fd trigger simultaneously to unblock this select.
In case of both fds, we use lwip's local thread semaphore, so we only
have to try return it (if it was taken/triggered more than once) when
we exit select().
Closes https://github.com/espressif/esp-idf/issues/8896
Bluetooth: disable PLL track function for ESP32-C3/ESP32-S3 as it introduced coexistence issues(bacport v4.4)
See merge request espressif/esp-idf!18139
Clang outputs performance warnings by default for atomic operations with
access size more then 4 bytes. So add "-Wno-atomic-alignment add" flag to
ESP-IDF cmake script.
'read' function should return 0 when encountering an end of file. When
newlib calls read and sees EOF returned, it assumes that this
condition is permanent and never calls 'read' for this file again
(unless the read pointer is moved using fseek).
The correct behavior in case no characters were received over UART is
to return -1. In this case newlib will retry reading from file on next
call to fread, fgetc or another function which calls __srefill_r.
introduced in e44ead5356
1. The int8M power domain config by default is PD. While LEDC is using
RTC8M as clock source, this power domain will be kept on.
But when 8MD256 is used as RTC clock source, the power domain should
also be kept on.
On ESP32, there was protection for it, but broken by commit
e44ead5356. Currently the power domain
will be forced on when LEDC is using RTC8M as clock source &&
!int8m_pd_en (user enable ESP_PDP_DOMAIN_RTC8M in lightsleep). Otherwise
the power domain will be powered off, regardless of RTC clock source.
In other words, int8M domain will be forced off (even when 8MD256
used as RTC clock source) if LEDC not using RTC8M as clock source, user
doesn't enable ESP_PDP_DOMAIN_RTC8M, or in deep sleep.
On later chips, there's no such protection, so 8MD256 could't be used as
RTC clock source in sleep modes.
This commit adds protection of 8MD256 clock to other chips. Fixes the
incorrect protection logic overriding on ESP32. Now the power domain
will be determiend by the logic below (order by priority):
1. When RTC clock source uses 8MD256, power up
2. When LEDC uses RTC8M clock source, power up
3. In deepsleep, power down
4. Otherwise determined by user config of ESP_PDP_DOMAIN_RTC8M,
power down by default. (This is preferred to have highest
priority, but it's kept as is because of current code structure.)
2. Before, after the macro `RTC_SLEEP_CONFIG_DEFAULT` decides dbias, the
protection above may force the int8m PU. This may cause the inconsistent
of dbias and the int8m PU status.
This commit lifts the logic of pd int8m/xtal fpu logic to upper layer
(sleep_modes.c).
Related: https://github.com/espressif/esp-idf/issues/8007, https://github.com/espressif/esp-idf/pull/8089
temp
fix(server): Fix websocket server not support handle multiple connections when client send CLOSE frame (backport v4.4)
See merge request espressif/esp-idf!18018
ESP-IDF v4.4 supports Python 3.6 or newer. F-strings are available there
but idf_tools.py can fail if run with older Pythons because the Python
version check is done later.
Closes https://github.com/espressif/esp-idf/issues/8890
Prior to this change "esp_wifi_clear_default_wifi_driver_and_handlers"
will not remove netif pointer from table when both AP and STA interfaces were
created and destroying default wifi interfaces is done in unfortunate
order. As a result there is dangling pointer left and it may cause crash in
later code (i.e. when esp_wifi_stop() is called).
ESP32-S2 and ESP32-S3
supports up to 1 GB of external flash and RAM
add support for
- 32MB
- 64MB
- 128MB ( example NOR spiFLASH 1G-BIT W25Q01JVZEIQ Winbond 0xEF 0x40 0x21 )
Merges https://github.com/espressif/esp-idf/pull/7688
Signed-off-by: Ivan Grokhotkov <ivan@espressif.com>
The compiler was not informed that the assembly block should be
treated as a memory barrier and could optimize out the initialization
of local arrays which could be used as semihosting arguments.
This resulted in garbage values being passed as semihosting call
arguments.
Additionally this commit changes the approach for placing values into
specific register. Instead of clobbers, local register variables are
used. This results in simpler generated code, since the compiler is
able to place values directly into the registers used for semihosting
arguments, avoiding additional moves.
LVGL porting examples are temporarily left in test folder.
Now we can remove it, as we have lvgl examples in esp-idf.
And lvgl v7 is legacy, we recommend to use lvgl v8
* Move filesystem mounting code into a separate file to simplify the
main source file.
* Clean up SDMMC and SDSPI related code. Move pin configuration into
Kconfig.
* Use same base_path ('/data') for either SPIFFS or SD. Remove the
check in file_server.c about the base path.
* Update README according to the changes above.
- Added a config option to set the minimum Certificate Verification
mode to Optional
- When this option is enabled, the peer (the client) certificate
is checked by the server, however the handshake continues even if
verification failed.
- By default, the peer certificate is not checked and ignored by the server.
Closes https://github.com/espressif/esp-idf/issues/8664
mask_get_id and gpio_hal_iomux_func_sel were called while cache
is disabled, but were not inlined as expected at -0O.
Force these functions to always be inlined.
These were called from IRAM context where the caller expect them to be inlined
and accessible when cache is disabled. This was not the case when compiled with -O0.
Closes https://github.com/espressif/esp-idf/issues/8301
While using esp_wifi_set_config, flag pmf_capable defaults to 0.
Users may not bother to enable it, which prevents connection to a
WPA3 AP. Or the AP may reset into WPA3 mode failing the re-connection.
To ensure better security, deprecate the pmf_capable flag and set it to
true internally.
This commit updates the USB Host Library as follows:
- usb_helpers.h
- Removed dependency on USB Host Library API
- Added function to print string descriptors
- usbh
- Fixed bug where an interface/endpoint could be claimed/allocated multiple times
- Removed redundant device ref_count change
- Added unit test for USB Host Library API usage
This commit updates the Hub Driver and USBH as follows:
- Updated communication mechanism between Hub Driver and USBH
- USBH notifies the Hub Driver via Hub request callback (usbh_hub_req_cb_t)
- Hub Driver notifies the USBH via usbh_hub_pass_event()
- Hub Driver now defers all event handling to hub_process.
- Hub Driver and USBH will now automatically recover the port after a disconnected
device has been closed.
- Fixed incorrect assert in usbh_dev_close()
Hub Driver is refactored as follows:
This commit update and refactors the Hub Driver as follows:
- Refactored enumeration state machine and stage functions
- Enumeration stage is now incremented
- Combined transfer stages of enumeration into common functions
- Comments updated
- Fixed usbh_hal_disable_debounce_lock() that would cause root_port_handle_events()
to fail the HCD_PORT_CMD_RESET call because the previous port connection interrupt
was not cleared.
The following features were added to the Hub Driver
- Enumeration config descriptor is now fetched in two separate stages
- Header is fetched first to determine the wTotalLength of the descriptor
- Fetching the full descriptor will request exactly wTotalLength bytes
- This works around some non-compliant devices that will babble/return zero
when requesting a length > wTotalLength
- Closes https://github.com/espressif/esp-idf/issues/7799
- Enumeration now stores string descriptors
- The Manufacturer, Product, and Serial Number string descriptors are
now read and stored during enumeration
- String descriptors are now part of usb_device_info_t
- Added unit test to test enumeration
This commit updates the USB Host stack to use the USB PHY driver. The
USB PHY and the OTG Controller should now both be setup/deleted using
usb_new_phy() and usb_del_phy() respectively.
- The hcd_install() now expects the USB PHY and OTG Contorller to be
already setup before it is called
- usb_host_install() now has an option to skip calling usb_del_phy() if
the user wants to setup their own USB PHY (e.g., in the case of using
and external PHY).
- CDC-ACM and MSC examples/test updated to use internal PHY
Closes https://github.com/espressif/esp-idf/issues/8061
This commit fixes the following bugs in the HCD
- HCD control pipes fill incorrect transfer size
_buffer_fill_ctrl() would fill the transfer descriptors length with
wLength instead of transfer->num_bytes. Therefore, the remaining length
would be incorrect when a control transfer requests more bytes than are
available.
- Fix USB_TRANSFER_FLAG_ZERO_PACK behavior
The previous behavior of USB_TRANSFER_FLAG_ZERO_PACK was incorrect, and did not
support interrupt pipes. A zero length packet can now be added to Bulk/Interrupt
OUT transfers where the length is a multiple of the endpoint's MPS.
- Fixed HCD port suspend and resume test case
Halting a control pipe mid control transfer can lead some test devices to get stuck
Avoid adding one extra fade cycle when performing a one-time duty update.
Add some notes to ledc_get_duty and ledc_update_duty APIs, so that users
are aware of when the new duty will be effective.
Closes https://github.com/espressif/esp-idf/issues/7288
(cherry picked from commit e175086226)
Closes https://github.com/espressif/esp-idf/issues/5571
Fix the bug that if the API was called from one core to free the interrupt source on the other core, it would trigger interrupt watchdog.
(cherry picked from commit 0e8286c57b)
As ESP32C3 does not have support for REF_TICK source clock, it is now not
possible to select it anymore.
Auto cfg clock has been improved for all boards.
Add following bugfixes
1. Station not able to connect when WPS pin is pressed first on AP.
2. PBC overlap getting detected for selected registrar PIN APs.
3. Station not considering authorised MACs for PIN method.
4. For PIN methodm If no AP is found, station will loop through
APs in its vicinity and try to do WPS with them one by one till
WPS timeout occurs. This is for some APs which do not set
selected registrar correctly.
Initial version of freemodbus master port files have been added to ESP-IDF based on https://github.com/armink/FreeModbus_Slave-Master-RTT-STM32.
The overall repository license, at the time of adding these files, has been BSD 3-clause. However at that time, several port files carried LGPL license headers. As the author of these files confirmed in https://github.com/armink/FreeModbus_Slave-Master-RTT-STM32/issues/61#issuecomment-977828450, this wasn't intentional. ESP-IDF version of modbus master port has been rewritten to target FreeRTOS instead of RT-Thread, but the license headers remained from the original version. This commit corrects this, replacing the license of these files with BSD 3-clause.
Calling "open" in CHECK_AND_CALL sets a perfectly correct errno.
There is no need to overwrite that with a value of ENOENT, since doing
so hides lower level errors like EIO.
Closes https://github.com/espressif/esp-idf/pull/8036
...and all their callers.
With the upcoming switch from sizeof(time_t)==4 to sizeof(time_t)==8,
sizeof(struct stat) is also increasing.
A few newlib functions present in ROM allocate 'struct stat' on the
stack and call _fstat_r on this structure. The implementation of
fstat is provided in ESP-IDF. This implementation will often do
memset(st, 0, sizeof(*st)), where st is 'struct stat*', before setting
some fields of this structure. If IDF is built with sizeof(st)
different from sizeof(st) which ROM was built with, this will lead
to an out-of-bounds write and a stack corruption.
This commit removes problematic ROM functions from the linker script.
Here are the functions which allocate 'struct stat':
* _isatty_r (in ROM)
* __swhatbuf_r, called by __smakebuf_r, called by __swsetup_r and
__srefill_r (in ROM)
* _fseeko_r (not in ROM)
* glob2 (not in ROM)
* _gettemp (not in ROM)
As a result, these functions are used from libc.a, and use correct
size of 'stat' structure.
Closes https://github.com/espressif/esp-idf/issues/7980
- Fixed logs expecting different format specifier
- Updated ignore list for check_public_header test
- Updated functions ported from mbedTLS
- Fix for make-system build errors
- Removed code regarding MBEDTLS_DYNAMIC_FREE_PEER_CERT
(config was kept for backward compatibility)
- Combined mbedTLS v2.28.x related options under a separate Kconfig menu
- For the wifi_prov_mgr example in release mode (with NDEBUG defined -
assertions disabled), the task to stop provisioning is never started
as it is voided by the assert function it is called in.
Closes https://github.com/espressif/esp-idf/issues/8309
fix: re-enabled fatfs r/w test on sdspi
fix: copyright notice
add: pin definitions for esp32c3
fix: Changed fixed spi dma channel to a macro definition
docs: Update incorrect pins for S3 documentation, set a default value for future targets, and remove line breaks inside paragraphs (backport v4.4)
See merge request espressif/esp-idf!16367
export PYTHONPATH="$IDF_PATH/tools:$IDF_PATH/tools/ci/python_packages"
python -m pip install -r $IDF_PATH/tools/ci/python_packages/ttfw_idf/requirements.txt
It helps to fix the ModuleNotFoundError issue with ttfw_idf and tiny_test_fw modules.
Closes https://github.com/espressif/esp-idf/issues/7815
- Check if pip is installed for sys.executable before attempting to
create the virtual environment, bail out with an error if not.
- Don't pass --seeder argument to virtualenv if its version is
too old. For example, on Ubuntu 18.04, virtualenv 15.1.0 doesn't
support this argument.
- Pass --python argument to virtualenv to request specific interpreter
to be used.
Closes https://github.com/espressif/esp-idf/issues/8045
Some tests check if certain files are rebuilt when source files are
'touch'ed. With ccache, 'touch'ing source files doesn't cause a
rebuild, hence the test fails. In case IDF_CCACHE_ENABLE was set in
the environment, unset it before starting the tests.
This commit refactors the FreeRTOS documentation as follows:
- Rewrite FreeRTOS SMP changes document (ESP-IDF FreeRTOS SMP)
- Reorganized sections in kernel behavior changes
- Rewrote descriptions of each kernel behavior changes
- Added notes about using ESP-IDF FreeRTOS for single core targets
- Moved TLSP callback section to FreeRTOS Additions document
- Moved FreeRTOS configuration section to FreeRTOS API document
- Added notes about FreeRTOS applications in ESP-IDF
- add missing Wi-Fi header MD5 checks for esp32c3, esp32s3
- check PHY libraries for references to ets_printf, in addition to
checking Wi-Fi libraries. This used to happen until libphy.a was
moved into a separate submodule.
Reported in https://github.com/espressif/esp-phy-lib/issues/3
time we can't find old device to be replaced,then this can cause crash. So we need
to change the way to malloc the new device or replace the old in the list.
Reason:
For example, if an url is lack of leading 'http:' by mistake, it causes to http_parser_parse_url() cannot parse http host item,
and then pass the null host pointer to _get_host_header(), crash happens.
Fix:
http added null pointer check now.
Closes https://jira.espressif.com:8443/browse/ESPAT-953
xPortStartScheduler calls vPortSetupTimer -> _frxt_tick_timer_init,
which enables tick timer interrupt and sets up the first timeout.
From that point on, the interrupt can fire. If the interrupt happens
while _frxt_dispatch is running, the scheduler will enter an infinite
loop. This is because _frxt_dispatch isn't supposed to be preemptable,
and the tick interrupt will overwrite some of the registers used by
_frxt_dispatch.
Note that this situation doesn't practically occur on the real
hardware, where the execution of vPortSetupTimer and _frxt_dispatch
happens quickly enough. However it can be reproduced on an emulator
if the tick period is set to 1ms.
Add an explicit call to portDISABLE_INTERRUPTS in xPortStartScheduler
to guarantee that _frxt_dispatch doesn't run with interrupts enabled.
This is similar to the esprv_intc_int_set_threshold(1); call in
RISC-V version of port.c.
Current issue: output reports sent by Windows not received.
The report characteristic declaration should also support write without
response as specified by HIDS profile:
See https://www.bluetooth.com/specifications/GATT/ (page 14)
This bugfix contains 3 fixes:
1. .rtc_dummy section is removed (not needed for C3)
2. .rtc_text section is padded with 16B for possible CPU prefetch
3. .rtc_text section is aligned to 4B boundary to comply with PMS Memprot requirements
[Coexistence]: fixed BLE scannable extended adv performance issue in case of Wi-Fi coexistence(backport v4.4)
See merge request espressif/esp-idf!16476
Fix a bug that could return a chunk of memory smaller than requested,
easily leading to a memory corruption, when the required memory alignment
passed to the allocator is 4.
This commit adds missing INCLUDE_ configurations to FreeRTOSConfig.h for
the following functions:
- xTaskAbortDelay()
- xTaskGetHandle()
Unit tests for these functions were also added.
Closes https://github.com/espressif/esp-idf/issues/7902
* Adds implementations of __{atomic,sync}_nand_fetch_n. These builtins
were implemented for other operations but were not defined for NAND.
* Adds implementation of __atomic_OP_fetch_n for all OPs.
* Adds implementation of __sync_OP_and_fetch_n for all OPs.
Reported in https://github.com/espressif/arduino-esp32/issues/5948
1. fix(pp): fix fragment plt loss when 2td pn compare with 1th pn
2. pmf allow keyindex in big endian format to workaround faulty APs
3. docs: update miswritten and abbreviated words and syntax errors for initialize WiFi section in esp_wifi.h header file
4. allow for minimal scope of wifi_init_config_t
ADC calibration scheme and algorithm are not changed. Only the eFuse bit BLOCK1_VERSION is changed. This MR updated the logic to recognize the adc efuse version
"can set sleep wake stub from stack in RTC RAM" would randomly fail on S3 due to stack overflow.
Fixed wrong usage of stack size and slightly increased it.
1. Fix FTM failures after repeated operations
2. Update Mexico channel refer to FCC
3. Mesh: fix the issue that layer2 node connect to lower-layer node when FIXED-ROOT root disappeared
4. Decouple softap and 8684 support
lw-ip: Update LWIP_DHCP_OPTIONS_LEN default value when LWIP_DHCP_DISABLE_VENDOR_CLASS_ID disabled(backport v4.4)
See merge request espressif/esp-idf!16253
In commit de22f3a4e5, combination of
hardware and software MPI (bignum) related approach was used to
work around chip (e.g. ESP32-C3) limitation of max 3072 bits support.
This was done using linker "--wrap" flag but since the relevant API is
being used in same translation (compilation unit), hardware mode was not
getting used in some cases (e.g., RSA key generation).
This commit modified internal mbedTLS API and makes software+hardware
combination deterministic.
The release of the semaphore indicating the item was successfully sent must be the last semaphore released. The receiver may be in another task and may delete the Ringbuffer (such as with a return code across tasks design pattern) if they are through with the Ringbuffer.
The function xRingbufferSendAcquire followed by xRingbufferSendComplete had the semaphores released in the proper order and that same pattern should have been used in xRingbufferSend and xRingbufferSendFromISR. This commit fixes this order.
Issue (IDFGH-6030) #7716 describes the problem in more detail.
Closes IDFGH-6030, https://github.com/espressif/esp-idf/issues/7716
Closes IDFGH-6036, https://github.com/espressif/esp-idf/pull/7721
ringbuf: Fix bug where comparision between a signed and unsigned operand resulted in incorrect free size for no-split/allow-split buffers (v4.4)
See merge request espressif/esp-idf!15881
This function resets the spinlock given as a parameter after taking it
(when entering the critical section). This then results in a panic once
it tries to exit the same critical section.
* Closes https://github.com/espressif/esp-idf/issues/7725
When building with BOOTLOADER_LOG_LEVEL lesser then VERBOSE, an error
code variable was being set but not consumed, resulting in a compiler
warning.
Signed-off-by: Gustavo Henrique Nihei <gustavo.nihei@espressif.com>
Builds for every chip other than ESP32 resulted in a compiler warning
due to "drom_load_addr_aligned" and "irom_load_addr_aligned" not being
used, besides being possible to actually reuse them.
Furthermore, extended the logic for the other similar variables.
Signed-off-by: Gustavo Henrique Nihei <gustavo.nihei@espressif.com>
This issue was earlier fixed in commit 79e74e5d5f
but during migration to newer FreeRTOS release, it got introduced again.
This commit fixes thread safety issues with configASSERT() calls
regarding the value of uxSchedulerSuspended. A false negative
occurs if a context switch to the opposite core occurs in between
the getting the core ID and the assesment.
Relevant https://github.com/espressif/esp-idf/issues/4230
Closes https://github.com/espressif/esp-idf/issues/7726
Closes IDFGH-6041
When the build runner has a local git mirror configured via
LOCAL_GIT_MIRROR variable, use that mirror when cloning IDF insider
the docker build job. Follows similar logic for
LOCAL_GITLAB_HTTPS_HOST, which is used for geo nodes.
The body of the bootloader_debug_buffer function was conditioned to
macros that were never defined, resulting in deactivated code.
Signed-off-by: Gustavo Henrique Nihei <gustavo.nihei@espressif.com>
For the CID10564,10384,10280,10098,10038,The memory was released in other place.
For the CID10365,it release the memory in the function when sent successfully.
For the CID10268,10011, we need not change the code.
Add TRY_ENTRY_CRITICAL() API to all for timeouts when entering critical sections.
The following port API were added:
- portTRY_ENTER_CRITICAL()
- portTRY_ENTER_CRITICAL_ISR()
- portTRY_ENTER_CRITICAL_SAFE()
Deprecated legacy spinlock API in favor of spinlock.h. The following API were deprecated:
- vPortCPUInitializeMutex()
- vPortCPUAcquireMutex()
- vPortCPUAcquireMutexTimeout()
- vPortCPUReleaseMutex()
Other Changes:
- Added portMUX_INITIALIZE() to replace vPortCPUInitializeMutex()
- The assembly of the critical section functions ends up being about 50 instructions longer,
thus the spinlock test pass threshold had to be increased to account for the extra runtime.
Closes https://github.com/espressif/esp-idf/issues/5301
During the early start, the virtual eFuse mode can call erase operations when OS is not yet running.
Possible workaround: CONFIG_SPI_FLASH_YIELD_DURING_ERASE=n
Fixed for the legacy flash driver as well.
This prevents the compiler error for the implicit declaration of
function "esp_rom_printf".
Signed-off-by: Gustavo Henrique Nihei <gustavo.nihei@espressif.com>
With strict debugging, i.e. `Set-PSDebug -strict`, execution of export.ps1 will
report the following error:
```
The variable '$envars_array' cannot be retrieved because it has not been set.
At C:\path\to\export.ps1:15 char:1
+ $envars_array # will be filled like:
+ ~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (envars_array:String) [], RuntimeException
+ FullyQualifiedErrorId : VariableIsUndefined
```
Closes https://github.com/espressif/esp-idf/pull/7819
This commit updates the USB Host Library API in the following wasy:
- usb_host_client_handle_t and usb_device_handle_t made into struct pointers
to generate compiler warnings about conflicting handle types
- usb_host_client_config_t changed to future proof API for Synchronous Clients
- Added usb_host_lib_unblock()
- Added usb_host_device_addr_list_fill()
- Return of usb_host_device_free_all() updated to indicate whether there
are still devices yet to be freed.
- Blockg APIs are now marked explicitly
- Fixed a bug in usb_host_transfer_submit_control() when checking the bEndpointAddress
of a control transfer.
Tests are also refactored to move some common macros into shared headers
Closes https://github.com/espressif/esp-idf/issues/7786
This commit fixes how the USBH handling of a sudden device disconnection,
more specifically handling of device gone.
- Previously the USBH would only halt, flush, and dequeue the device's
default EP, then send a device gone event to the Host Library layer.
- Now the USBH will also halt and flush all non-default EPs, allowing
all of the URBs to be dequeud.
- Some internal object members are now protected by a mutex instead of
a spinlock.
Closes https://github.com/espressif/esp-idf/issues/7505
This commit fixes how the USB Host HCD handles sudden disconnections.
Bugs:
- HW channels remain active when the port suddenly disconnects, and
previously the channel would be disabled by setting the disabled bit,
then waiting for a disabled interrupt. However, ISOC channels do not
generate the disabled interrupt when the port is invalid, thus leading
to tasks getting indefinitely blocked in hcd_pipe_command().
Fix:
On a sudden disconnection, forcibly treat all channels as halted even
if their HCCHAR.ChEna bit is still set. We do a soft reset after a port
error anyways, so the channels will eventually be reset.
Closes https://github.com/espressif/esp-idf/issues/7505
This commit addes the 8/16 bit register field access workarounds to
the DWC_OTG peripheral. This workaround was applied to all other
peripherals in commit 874a720286.
The previous SMP freertos round robin would skip over tasks when
time slicing. This commit implements a Best Effort Round Robin
where selected tasks are put to the back of the list, thus
makes the time slicing more fair.
- Documentation has been updated accordingly.
- Tidy up vTaskSwitchContext() to match v10.4.3 more
- Increased esp_ipc task stack size to avoid overflow
Closes https://github.com/espressif/esp-idf/issues/7256
This commit removes the following critical nested macros as follows:
- portENTER_CRITICAL_NESTED()
- portEXIT_CRITICAL_NESTED()
They are replaced with portSET_INTERRUPT_MASK_FROM_ISR() and
portCLEAR_INTERRUPT_MASK_FROM_ISR() which are the proper FreeRTOS interfaces.
Created a portmacro_deprecated.h for each port to contain deprecated API
that were originally from portmacro.h
This commit fixes a bug in no-split and allow-split ring buffers free buffer size calculation.
When the free size available in the buffers less than the size of one item header,
the function prvGetCurMaxSizeNoSplit/AllowSplit() incorrectly returned the maxItemSize instead of 0.
This is due to the comparision between a negative and a positive value
where both operands are treated as unsigned during the comparision operation,
thereby treating the negative operand as a large integer.
Also added new unit tests to test buffer-full and almost-full conditions
where this scenario is likely to be hit.
Closes https://github.com/espressif/esp-idf/issues/7344
Closes https://github.com/espressif/esp-idf/pull/7371
FATFS provides a disk status and disk initialize callback which were not
implemented. Implementation has very low impact on SD/MMC speed and
fixes issues, when trying to open file when SD card was removed from
slot and not deinited.
If disk_status returns STA_NOINIT, it will always continue with
disk_initialize. If that returns 0, it will continue like everything is
working normally. So there has to be the same check as in disk_status.
Return of disk_initialize is always checked like this for STA_NOINIT or
STA_PROTECT so if command fails, we return the STA_NOINIT.
stat = disk_initialize(pdrv);
if (stat & STA_NOINIT) return FR_NOT_READY;
if (stat & STA_PROTECT) return FR_WRITE_PROTECTED;
Closes IDF-4125
This commit fixes issue where empty (unprogrammed) digest slot out of
multiple supported (e.g. 3 for ESP32-C3) could cause issue in
workflow enablement process.
Notes:
1. This issue was applicable for chips supporting "secure-boot-v2"
scheme with multiple digests slots
2. This issue was affecting only manual workflow, where digest of
public was pre-flashed in efuse
3. Change in "flash_encrypt.c" is only for additional safety purpose
Increase reset assertion time from 100µs (as specified minimum in the datasheet) to 150µs.
Some specimen of the LAN8720 need the reset signal asserted longer than 100µs to initialise properly. Otherwise they are in a zombie state where they are establishing and loosing an Ethernet link once in a seconds interval.
Tokenizing data by '\n' will effectively replace all LF characters by '\0' so checking for phantom lines has to be adjusted:
* minimal empty line is CR only (strlen = 1)
* checking for lines containing CR only
This commit adds the following hook functions to obtain memory
for the IDLE and Timer Daemon tasks when configSUPPORT_STATIC_ALLOCATION
is enabled:
- vApplicationGetIdleTaskMemory()
- vApplicationGetTimerTaskMemory()
Currently, both functions simply allocate from the same memory as
regular tasks (i.e., internal memory for both the stack and TCB)
Closes https://github.com/espressif/esp-idf/issues/7511
esp_restart()/panic_restart() never resets the Digital system (so far required only by the Memprot feature) as there's a typo in the corresponding #define:
it checks CONFIG_ESP_SYSTEM_CONFIG_MEMPROT_FEATURE instead of CONFIG_ESP_SYSTEM_MEMPROT_FEATURE.
Issue fixed.
IDF-4094
The issue is related to the non-sequential way of description when
such fields going together sequential.
Related to esp32h2 chip for eFuses: MAC_FACTORY and MAC_EXT.
The issue is in wrong indexes of MAC_EXT.
MAC_EXT got indexes like it is joined to MAC_FACTORY.
const esp_efuse_desc_t* ESP_EFUSE_MAC_FACTORY[] = {
&MAC_FACTORY[0],
&MAC_FACTORY[1],
&MAC_FACTORY[2],
&MAC_FACTORY[3],
&MAC_FACTORY[4],
&MAC_FACTORY[5],
NULL
};
const esp_efuse_desc_t* ESP_EFUSE_MAC_EXT[] = {
&MAC_EXT[6],
&MAC_EXT[7],
NULL
};
This commit fixed it to:
const esp_efuse_desc_t* ESP_EFUSE_MAC_EXT[] = {
&MAC_EXT[0],
&MAC_EXT[1],
NULL
};
esp_http_client: Fix HEAD request will affect the all next HTTP requests unless we close the HTTP request(backport v4.4)
See merge request espressif/esp-idf!15715
In 4972605, high-level interrupt handler hook was renamed from
ld_include_highint_hdl to ld_include_panic_highint_hdl. However the
change wasn't applied in GNU Make based build system. As a result,
the default interrupt handler was linked and features which depended
on the high-level interrupt didn't work.
Closes https://github.com/espressif/esp-idf/issues/7759
Closes https://github.com/espressif/esp-idf/issues/7447
Switching back from data (PPP) mode to command mode must be done is the following sequence:
* No characters entered for T1 time (1 second)
* "+++" characters entered with no characters in between (1 second)
* No characters entered for T1 timer (1 second)
(per specification of SIM800 SIM800_Series_AT_Command_Manual_V1.09.pdf)
Related https://github.com/espressif/esp-idf/issues/7608
Regression from e68afcb45036901ebc9174b2c8f3804f7921410c causing
non-clean builds for standard asio-ssl example (warning was
suppressed in the CI build only)
In esp_dte_handle_line(), it tokenize the data to call handlers separately
for each *line*. So it needs to post the tokenized data when report unknown
line instead of the first token (which could be a '\r' in my test).
Fixes: 336de29413 ("Examples/pppos_client: Fix manual parsing to accept unexpected lines")
Signed-off-by: Axel Lin <axel.lin@gmail.com>
2021-10-18 10:14:31 +08:00
21378 changed files with 1779026 additions and 3547589 deletions
description:Before submitting a new issue, please follow the checklist and try to find the answer.
options:
- label:I have read the documentation [ESP-IDF Programming Guide](https://docs.espressif.com/projects/esp-idf/en/latest/) and the issue is not addressed there.
required:true
- label:I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
required:true
- label:I have searched the issue tracker for a similar issue and not found a similar issue.
required:true
- type:input
id:idf_version
attributes:
label:IDF version.
description:Onwhich IDF version does this issue occur on? Run `git describe --tags` to find it.
placeholder:ex. v3.2-dev-1148-g96cd3b75c
validations:
required:true
- type:dropdown
id:operating_system
attributes:
label:Operating System used.
multiple:false
options:
- Windows
- Linux
- macOS
validations:
required:true
- type:dropdown
id:build
attributes:
label:How did you build your project?
multiple:false
options:
- Command line with Make
- Command line with CMake
- Command line with idf.py
- Eclipse IDE
- CLion IDE
- VS Code IDE
- Other (please specify in More Information)
validations:
required:true
- type:dropdown
id:windows_comand_line
attributes:
label:If you are using Windows, please specify command line type.
multiple:false
options:
- PowerShell
- CMD
validations:
required:false
- type:textarea
id:expected
attributes:
label:What is the expected behavior?
description:Please provide a clear and concise description of the expected behavior.
placeholder:I expected it to...
validations:
required:true
- type:textarea
id:actual
attributes:
label:What is the actual behavior?
description:Please describe actual behavior.
placeholder:Instead it...
validations:
required:true
- type:textarea
id:steps
attributes:
label:Steps to reproduce.
description:'How do you trigger this bug? Please walk us through it step by step. If this is build bug, please attach sdkconfig file (from your project folder). Please attach your code here.'
value:|
1. Step
2. Step
3. Step
...
validations:
required:true
- type:textarea
id:debug_logs
attributes:
label:Build or installation Logs.
description:Build or installation log goes here, should contain the backtrace, as well as the reset source if it is a crash.
placeholder:Your log goes here.
render:plain
validations:
required:false
- type:textarea
id:diag
attributes:
label:Diagnostic report archive.
description:|
Diagnostic report for ESP-IDF created using [idf.py diag](https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-guides/tools/idf-diag.html) or [esp-idf-diag](https://github.com/espressif/esp-idf-diag). The `idf.py diag` command is available beginning with ESP-IDF version 5.5. For older versions, you may want to consider using the `esp-idf-diag` command.
In your project directory, execute the following command:
Using `idf.py diag`
1. idf.py diag
Using `esp-idf-diag`
1. pip install esp-idf-diag
2. esp-idf-diag create
Once the report is generated, the tool will guide you with the next steps.
placeholder:Please attach the diagnostic report zip file here.
validations:
required:false
- type:textarea
id:more-info
attributes:
label:More Information.
description:Do you have any other information from investigating this?
placeholder:ex. I tried on my friend's Windows 10 PC and the command works there.
description:Before submitting a new issue, please follow the checklist and try to find the answer.
options:
- label:I have read the documentation [ESP-IDF Programming Guide](https://docs.espressif.com/projects/esp-idf/en/latest/) and the issue is not addressed there.
required:true
- label:I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
required:true
- label:I have searched the issue tracker for a similar issue and not found a similar issue.
required:true
- type:input
id:idf_version
attributes:
label:IDF version.
description:Onwhich IDF version does this issue occur on? Run `git describe --tags` to find it.
placeholder:ex. v3.2-dev-1148-g96cd3b75c
validations:
required:true
- type:input
id:chip_revision
attributes:
label:Espressif SoC revision.
description:Onwhich Espressif SoC revision does your application run on? Run `esptool chip-id` to find it.
placeholder:ex. ESP32-C3 (QFN32) (revision v0.3)
validations:
required:true
- type:dropdown
id:operating_system
attributes:
label:Operating System used.
multiple:false
options:
- Windows
- Linux
- macOS
validations:
required:true
- type:dropdown
id:build
attributes:
label:How did you build your project?
multiple:false
options:
- Command line with Make
- Command line with CMake
- Command line with idf.py
- Eclipse IDE
- CLion IDE
- VS Code IDE
- Other (please specify in More Information)
validations:
required:true
- type:dropdown
id:windows_comand_line
attributes:
label:If you are using Windows, please specify command line type.
multiple:false
options:
- PowerShell
- CMD
validations:
required:false
- type:input
id:devkit
attributes:
label:Development Kit.
description:Onwhich Development Kit does this issue occur on?
description:Please provide a clear and concise description of the expected behavior.
placeholder:I expected it to...
validations:
required:true
- type:textarea
id:actual
attributes:
label:What is the actual behavior?
description:Please describe actual behavior.
placeholder:Instead it...
validations:
required:true
- type:textarea
id:steps
attributes:
label:Steps to reproduce.
description:'How do you trigger this bug? Please walk us through it step by step. Please attach your code here.'
value:|
1. Step
2. Step
3. Step
...
validations:
required:true
- type:textarea
id:debug_logs
attributes:
label:Debug Logs.
description:Debug log goes here, should contain the backtrace, as well as the reset source if it is a crash.
placeholder:Your log goes here.
render:plain
validations:
required:false
- type:textarea
id:diag
attributes:
label:Diagnostic report archive.
description:|
Diagnostic report for ESP-IDF created using [idf.py diag](https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-guides/tools/idf-diag.html) or [esp-idf-diag](https://github.com/espressif/esp-idf-diag). The `idf.py diag` command is available beginning with ESP-IDF version 5.5. For older versions, you may want to consider using the `esp-idf-diag` command.
In your project directory, execute the following command:
Using `idf.py diag`
1. idf.py diag
Using `esp-idf-diag`
1. pip install esp-idf-diag
2. esp-idf-diag create
Once the report is generated, the tool will guide you with the next steps.
placeholder:Please attach the diagnostic report zip file here.
validations:
required:false
- type:textarea
id:more-info
attributes:
label:More Information.
description:Do you have any other information from investigating this?
placeholder:ex. I tried on my friend's Windows 10 PC and the command works there.
* We welcome any ideas or feature requests! It’s helpful if you can explain exactly why the feature would be useful.
* There are usually some outstanding feature requests in the [existing issues list](https://github.com/espressif/esp-idf/labels/Type%3A%20Feature%20Request), feel free to add comments to them.
* If you would like to contribute, please read the [contributions guide](https://docs.espressif.com/projects/esp-idf/en/stable/esp32/contribute/index.html).
- type:textarea
id:problem-related
attributes:
label:Is your feature request related to a problem?
description:Please provide a clear and concise description of what the problem is.
placeholder:ex. I'm always frustrated when ...
- type:textarea
id:solution
attributes:
label:Describe the solution you'd like.
description:Please provide a clear and concise description of what you want to happen.
placeholder:ex. When connecting to an Espressif chip ...
- type:textarea
id:alternatives
attributes:
label:Describe alternatives you've considered.
description:Please provide a clear and concise description of any alternative solutions or features you've considered.
placeholder:ex. Choosing other approach wouldn't work, because ...
- type:textarea
id:context
attributes:
label:Additional context.
description:Please add any other context or screenshots about the feature request here.
description:Before submitting a new issue, please follow the checklist and try to find the answer.
options:
- label:I have read the documentation [ESP-IDF Programming Guide](https://docs.espressif.com/projects/esp-idf/en/latest/) and the issue is not addressed there.
required:true
- label:I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
required:true
- label:I have searched the issue tracker for a similar issue and not found a similar issue.
**Reminder: If your issue is a general question, starts similar to "How do I..", or is related to 3rd party development kits/libs, please discuss this on our community forum at https://esp32.com instead.**
INSTRUCTIONS
============
Before submitting a new issue, please follow the checklist and try to find the answer.
- [ ] I have read the documentation [ESP-IDF Programming Guide](https://docs.espressif.com/projects/esp-idf/en/latest/) and the issue is not addressed there.
- [ ] I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
- [ ] I have searched the issue tracker for a similar issue and not found a similar issue.
If the issue cannot be solved after the steps before, please follow these instructions so we can get the needed information to help you in a quick and effective fashion.
1. Fill in all the fields under **Environment** marked with [ ] by picking the correct option for you in each case and deleting the others.
2. Describe your problem.
3. Include [debug logs from the "monitor" tool](https://docs.espressif.com/projects/esp-idf/en/latest/api-guides/tools/idf-monitor.html), or [coredumps](https://docs.espressif.com/projects/esp-idf/en/latest/api-guides/core_dump.html).
4. Providing as much information as possible under **Other items if possible** will help us locate and fix the problem.
5. Use [Markdown](https://guides.github.com/features/mastering-markdown/) (see formatting buttons above) and the Preview tab to check what the issue will look like.
6. Delete these instructions from the above to the below marker lines before submitting this issue.
**IMPORTANT: If you do not follow these instructions and provide the necessary details, your issue may not be resolved.**
- [Manifest File to Control the Build/Test apps](#manifest-file-to-control-the-buildtest-apps)
- [Grammar](#grammar)
- [Special Rules](#special-rules)
- [Upload/Download Artifacts to Internal Minio Server](#uploaddownload-artifacts-to-internal-minio-server)
- [Users Without Access to Minio](#users-without-access-to-minio)
- [Users With Access to Minio](#users-with-access-to-minio)
- [Env Vars for Minio](#env-vars-for-minio)
- [Artifacts Types and File Patterns](#artifacts-types-and-file-patterns)
- [Upload](#upload)
- [Download](#download)
## General Workflow
@@ -55,7 +45,6 @@
-`custom_test[_esp32/esp32s2/...]`
-`docker`
-`docs`
-`docs_full`, triggers a full docs build, regardless of files changed
-`example_test[_esp32/esp32s2/...]`
-`fuzzer_test`
-`host_test`
@@ -65,11 +54,13 @@
-`macos_test`
-`nvs_coverage`
-`submodule`
-`unit_test[_esp32/esp32s2/...]`
-`weekend_test`
-`windows`
There are two general labels (not recommended since these two labels will trigger a lot of jobs)
-`target_test`: includes all target for `example_test`, `custom_test`, `component_ut`, `integration_test`
-`target_test`: includes all target for `example_test`, `custom_test`, `component_ut`,`unit_test`,`integration_test`
-`all_test`: includes all test labels
### How to trigger a `detached` pipeline without pushing new commits?
@@ -117,7 +108,7 @@ curl -X POST --header "PRIVATE-TOKEN: [YOUR PERSONAL ACCESS TOKEN]" [GITLAB_SERV
```yaml
check_docs_lang_sync:
extends:
- .pre_check_template
- .pre_check_job_template
- .rules:build:docs
script:
- cd docs
@@ -145,11 +136,10 @@ check if there's a suitable `.if-<if-anchor-you-need>` anchor
1. if there is, create a rule following [`rules` Template Naming Rules](#rules-template-naming-rules).For detail information, please refer to [GitLab Documentation `rules-if`](https://docs.gitlab.com/ee/ci/yaml/README.html#rulesif). Here's an example.
```yaml
.rules:patterns:clang_tidy:
.rules:dev:
rules:
- <<: *if-protected
- <<: *if-trigger
- <<: *if-dev-push
changes: *patterns-c-files
```
2. if there isn't
@@ -198,7 +188,7 @@ if a name has multi phrases, use `-` to concatenate them.
-`target_test`
a combination of `example_test`, `custom_test`, `component_ut`, `integration_test` and all targets
a combination of `example_test`, `custom_test`,`unit_test`,`component_ut`, `integration_test` and all targets
#### `rules` Template Naming Rules
@@ -233,26 +223,3 @@ To run these commands in shell script locally, place `source tools/ci/utils.sh`
-`info`: log in green color
-`run_cmd`: run the command with duration seconds info
-`retry_failed`: run the command with duration seconds info, retry when failed
## Manifest File to Control the Build/Test apps
`.build-test-rules.yml` file is a manifest file to control if the CI is running the build and test job or not. The Supported Targets table in `README.md` for apps would be auto-generated by `pre-commit` from the app's `.build-test-rules.yml`.
### Grammar
We're using the latest version of [idf-build-apps][idf-build-apps]. Please refer to their [documentation][manifest-doc]
- if [ -n "$LOCAL_GITLAB_HTTPS_HOST" ]; then export LOCAL_CI_REPOSITORY_URL="https://gitlab-ci-token:${CI_JOB_TOKEN}@${LOCAL_GITLAB_HTTPS_HOST}/${CI_PROJECT_PATH}"; fi
- if [ -n "$LOCAL_GIT_MIRROR" ]; then export LOCAL_CI_REPOSITORY_URL="${LOCAL_GIT_MIRROR}/${CI_PROJECT_PATH}"; fi
- echo "Using repository at $LOCAL_CI_REPOSITORY_URL"
- git diff --exit-code -- ${IDF_TARGET}/esp_efuse_table.c || { echo 'Differences found for ${IDF_TARGET} target. Please run idf.py efuse-common-table and commit the changes.'; exit 1; }
- git diff --exit-code -- ${IDF_TARGET}/esp_efuse_table.c || { echo 'Differences found for ${IDF_TARGET} target. Please run make efuse_common_table or idf.py efuse-common-table and commit the changes.'; exit 1; }
@@ -10,7 +10,8 @@ _This entire section can be deleted if all items are checked._
* [ ] All related links, including JIRA, backport, submodule MR, are mentioned in the `Related` subsection.
* [ ] Any GitHub issues are linked inside the git commit message and corresponding release notes
* [ ] Add label for the area this MR is part of
* [ ] For documentation updates, check if label `needs translation:CN` or `needs translation:EN` have been added when the other language version still needs the update. Don't add such labels if the document updated has never been translated before and requires translation from scratch.
* [ ] For documentation updates, check if label `Docs` and `needs translation:CN` or `needs translation:EN` have been added when the other language version still needs the update. Skip adding the label if the document is not yet translated.
* [ ] Check if documents requiring translation fall under get-started section. If yes, add the labels mentioned above. Then the documentation team will assign a translator for you. Please inform the translator to prepare translation once your MR is ready to merge. The translation should be included in your MR to get it merged. For more information, see documentation workflow in Wiki.
* [ ] Any necessary "needs backport" labels are added
* [ ] Check if this is a breaking change. If it is, add notes to the `Breaking change notes` subsection below
* [ ] Release note entry if this is a new public feature, or a fix for an issue introduced in the previous release.
@@ -41,7 +42,7 @@ _For other small/non-public changes, which are not expected to be in the release
_Don't touch the subsection titles below, they will be parsed by scripts._
## Release notes <!-- Mandatory -->
## Release notes (Mandatory)
_Changes made in this MR that should go into the **Release Notes** should be listed here. Please use **past tense** and *specify the area (see maintainers page of IDF internal wiki)*. If there is a subscope, include it and separate with slash (`/`). Minor changes can go to the descriptions above without a release notes entry._
@@ -60,6 +61,3 @@ _If there are any breaking changes, please mention it here. Talking about (1) wh
_Please strictly follow the breaking change restriction, which means, if there is a breaking change but you are merging to non-major versions, you have to separate the breaking part out to another MR for a major version. The breaking change subsection is only accepted in MRs merging to major versions._
* [VFS/UART] Now vfs_uart_set_rts_cts accept one more instance argument, to support configuration to different ports.
<!-- Don't remove the next line - assigns the MR author as the assignee -->
# Compatibility Between ESP-IDF Releases and Revisions of Espressif SoCs
* [中文版](./COMPATIBILITY_CN.md)
Espressif keeps improving the performance of its SoCs by providing new chip revisions. However, some of the improvements require special software support. Some of the software supports are even mandatory for the chip revisions to run normally.
This document describes the compatibility between ESP-IDF releases and Espressif SoC revisions.
NOTE: This document on release branches may be out-of-date. Check the [Compatibility file on master](https://github.com/espressif/esp-idf/blob/master/COMPATIBILITY.md) for the most accurate information.
See [Compatibility Advisory for Chip Revision Numbering Scheme](https://www.espressif.com/sites/default/files/advisory_downloads/AR2022-005%20Compatibility%20Advisory%20for%20Chip%20Revision%20Numbering%20%20Scheme.pdf) on the versioning of Espressif SoC revisions.
You can run `esptool chip-id` to detect the series and revision of an SoC. See [SoC Errata](https://www.espressif.com/en/support/documents/technical-documents?keys=errata) for more on how to distinguish between chip revisions, and the improvements provided by chip revisions. And run `idf.py --version` to know the version of current ESP-IDF.
## ESP-IDF Support for Different Chip Revisions
The sections below show the requirements to ESP-IDF version of chip revisions. Each chip revision corresponds to specific `Recommended` and `Required` versions of ESP-IDF:
-`Recommended`: shows from which version of ESP-IDF you can make use of all the improvements of the chip revision. Running binary compiled with ESP-IDF below the `Recommended` version of a chip revision, software may not benefit from the bugfix/features provided by the chip revision. The chip will have almost the same behavior as its previous revision.
-`Required`: shows the minimum version required to run the chip revision normally. Running binary compiled below the `Required` version, the binary may have unpredictable behavior.
Though the software can make use of all the features of a chip revision, if its version is higher than the `Recommended` version of the chip, it is still recommended to use the latest bugfix version of the release branch. The latest bugfix version fixes a number of issues and helps improve product stability.
For example, if we have a chip, whose `Required`/`Recommended` version of `release/v5.1` branch is `v5.1.2`/`v5.1.4`, and the latest release on that branch is `v5.1.6`. Then the chip will not boot up with ESP-IDF `v5.1`-`v5.1.1` or will have unpredictable behavior, and application may not make use of all benefits of the chip, when running with ESP-IDF `v5.1.2` or `v5.1.3`. Though `v5.1.4` well supports the chip revision, it is still recommended to upgrade ESP-IDF to `v5.1.6`.
Note: IDF v5.1.5 and v5.3.2 are compatible with C2 v2.0. However the chip revision check hasn't been updated on these releases. Enable `ESP32C2_REV2_DEVELOPMENT` config to bypass the outdated check.
## What If the ESP-IDF Version Is Lower than the `Required` Version?
Latest ESP-IDF versions can prevent from downloading to, or even execute binaries on unsupported chips. ESP-IDF of versions v4.4.5+, v5.0.1+, v5.1 and above have both esptool download check and bootloader loading check against the chip revision. While ESP-IDF v4.3.5 has only esptool downloading check.
For earlier ESP-IDF versions without such checking, which is incompatible with the given chip revision, the chips running such versions will have unpredictable behavior.
Contributions to esp-idf - fixing bugs, adding features, adding documentation - are welcome. We accept contributions via `Github Pull Requests <https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/about-pull-requests>`_.
Before Contributing
-------------------
Before sending us a Pull Request, please consider this list of points:
* Is the contribution entirely your own work, or already licensed under an Apache License 2.0 compatible Open Source License? If not then we unfortunately cannot accept it.
* Does any new code conform to the esp-idf :doc:`Style Guide <style-guide>`?
* Have you installed the :doc:`pre-commit hook <install-pre-commit-hook>` for esp-idf project?
* Does the code documentation follow requirements in :doc:`documenting-code`?
* Is the code adequately commented for people to understand how it is structured?
* Is there documentation or examples that go with code contributions? There are additional suggestions for writing good examples in :idf:`examples` readme.
* Are comments and documentation written in clear English, with no spelling or grammar errors?
* Example contributions are also welcome. Please check the :doc:`creating-examples` guide for these.
* If the contribution contains multiple commits, are they grouped together into logical changes (one major change per pull request)? Are any commits with names like "fixed typo" `squashed into previous commits <https://eli.thegreenplace.net/2014/02/19/squashing-github-pull-requests-into-a-single-commit/>`_?
* If you're unsure about any of these points, please open the Pull Request anyhow and then ask us for feedback.
Pull Request Process
--------------------
After you open the Pull Request, there will probably be some discussion in the comments field of the request itself.
Once the Pull Request is ready to merge, it will first be merged into our internal git system for in-house automated testing.
If this process passes, it will be merged onto the public github repository.
Legal Part
----------
Before a contribution can be accepted, you will need to sign our :doc:`contributor-agreement`. You will be prompted for this automatically as part of the Pull Request process.
- Please read [the support policy](SUPPORT_POLICY.md) and [the documentation](https://docs.espressif.com/projects/esp-idf/en/latest/esp32/versions.html) for more information about ESP-IDF versions.
- Please see the [End-of-Life Advisories](https://www.espressif.com/en/support/documents/advisories?keys=&field_type_of_advisory_tid%5B%5D=817) for information about ESP-IDF releases with discontinued support.
# ESP-IDF Release and SoC Compatibility
The following table shows ESP-IDF support of Espressif SoCs where ![alt text][preview] and ![alt text][supported] denote preview status and support, respectively. The preview support is usually limited in time and intended for beta versions of chips. Please use an ESP-IDF release where the desired SoC is already supported.
The following table shows ESP-IDF support of Espressif SoCs where ![alt text][preview] and ![alt text][supported] denote preview status and support, respectively. In preview status the build is not yet enabled and some crucial parts could be missing (like documentation, datasheet). Please use an ESP-IDF release where the desired SoC is already supported.
There are variants of revisions for a series of chips. See [Compatibility Between ESP-IDF Releases and Revisions of Espressif SoCs](https://github.com/espressif/esp-idf/blob/master/COMPATIBILITY.md) for the details of the compatibility between ESP-IDF and chip revisions.
Espressif SoCs released before 2016 (ESP8266 and ESP8285) are supported by [RTOS SDK](https://github.com/espressif/ESP8266_RTOS_SDK) instead.
# Developing With ESP-IDF
@@ -46,9 +31,11 @@ See https://idf.espressif.com/ for links to detailed instructions on how to set
### Non-GitHub forks
ESP-IDF uses relative locations as its submodules URLs ([.gitmodules](.gitmodules)). So they link to GitHub. If ESP-IDF is forked to a Git repository which is not on GitHub, you will need to run the script [tools/set-submodules-to-github.sh](tools/set-submodules-to-github.sh) after git clone.
The script sets absolute URLs for all submodules, allowing `git submodule update --init --recursive` to complete. If cloning ESP-IDF from GitHub, this step is not needed.
ESP-IDF uses relative locations as its submodules URLs ([.gitmodules](.gitmodules)). So they link to GitHub.
If ESP-IDF is forked to a Git repository which is not on GitHub, you will need to run the script
[tools/set-submodules-to-github.sh](tools/set-submodules-to-github.sh) after git clone.
The script sets absolute URLs for all submodules, allowing `git submodule update --init --recursive` to complete.
If cloning ESP-IDF from GitHub, this step is not needed.
## Finding a Project
@@ -83,7 +70,7 @@ See the Getting Started guide links above for a detailed setup guide. This is a
## Flashing the Project
When the build finishes, it will print a command line to use `esptool` to flash the chip. However you can also do this automatically by running:
When the build finishes, it will print a command line to use esptool.py to flash the chip. However you can also do this automatically by running:
`idf.py -p PORT flash`
@@ -95,7 +82,7 @@ You don't need to run `idf.py build` before running `idf.py flash`, `idf.py flas
## Viewing Serial Output
The `idf.py monitor` target uses the [esp-idf-monitor tool](https://github.com/espressif/esp-idf-monitor) to display serial output from Espressif SoCs. esp-idf-monitor also has a range of features to decode crash output and interact with the device. [Check the documentation page for details](https://docs.espressif.com/projects/esp-idf/en/latest/get-started/idf-monitor.html).
The `idf.py monitor` target uses the [idf_monitor tool](https://docs.espressif.com/projects/esp-idf/en/latest/get-started/idf-monitor.html) to display serial output from Espressif SoCs. idf_monitor also has a range of features to decode crash output and interact with the device. [Check the documentation page for details](https://docs.espressif.com/projects/esp-idf/en/latest/get-started/idf-monitor.html).
Exit the monitor by typing Ctrl-].
@@ -124,8 +111,6 @@ This can be combined with other targets, ie `idf.py -p PORT erase-flash flash` w
* Documentation for the latest version: https://docs.espressif.com/projects/esp-idf/. This documentation is built from the [docs directory](docs) of this repository.
* [Beginner's Guide to Key Concepts and Resources of ESP-IDF](https://youtu.be/J8zc8mMNKtc?feature=shared)
* The [esp32.com forum](https://esp32.com/) is a place to ask questions and find community resources.
* [Check the Issues section on github](https://github.com/espressif/esp-idf/issues) if you find a bug or have a feature request. Please check existing Issues before opening a new one.
This document outlines the goals of ESP-IDF project and is shared for the convenience of our customers. It is important to clarify that this document is not a binding commitment to our customers. Instead, its primary purpose is to offer a clear roadmap and direction for the project's development. By openly sharing this information, we aim to enhance our customers' understanding, promote transparency and ensure alignment with the overarching objectives of the ESP-IDF project.
## Project Overview
### Project Goals
In both minor and major releases, we integrate new chip support to enhance our product range. By expanding the chip matrix, we broaden the scope of our offerings, catering to a wider audience with diverse needs. This proactive approach ensures that our products remain at the forefront of technological advancements, consistently meeting and exceeding customer expectations.
Furthermore, we prioritize bugfix releases for active branches, focusing on improving the stability and performance of products already in production. By addressing bugs promptly, we aim to enhance the overall user experience and provide tangible benefits to customers relying on our solutions. This proactive maintenance strategy reflects our commitment to delivering reliable, high-quality products to our valued customer base.
Below are the main objectives that ESP-IDF project/teams would like to implement in 2025.
- New Chip Support
- Add support for ESP32-C5
- Add support for ESP32-C61
- More Minor/Major Releases
- Release IDF v5.5 in the middle of 2025
- Release IDF v6.0 at the end of 2025
- More Bugfix Releases
- Release v5.0.8 and v5.0.9 before ESP-IDF v5.0 goes End of Life in May 2025
- Release v5.1.6 and v5.1.7 before ESP-IDF v5.1 goes End of Life in December 2025
- Do more bugfix releases for IDF v5.2 and IDF v5.3 before release/5.2 and release/5.3 enter maintenance period
- Do more bug fixes releases for release/5.4 and release/5.5, and push the two releases to be more stable and production-ready
- Major Changes
- We plan to upgrade MbedTLS to v4.x series in IDF v6.0. In addition, we will also be migrating to newer PSA crypto API as part of this upgrade. Please note that this may involve some breaking changes on the application side for the crypto API usage.
Please note that support status of previous silicones could be found on [ESP-IDF Release and SoC Compatibility](https://github.com/espressif/esp-idf#esp-idf-release-and-soc-compatibility).
### Roadmap Details
The ESP-IDF project prioritizes consistent maintenance and updates to ensure our customers remain at the forefront of technological advancements. Our commitment to ongoing development ensures that customers continuously benefit from the latest innovations in the field.
Moreover, we are dedicated to empowering our customers to leverage newly implemented features and enhanced functionalities through iterative improvements. Our steadfast commitment to pushing boundaries ensures that clients not only keep pace with evolving technology but also extract optimal value from the cutting-edge capabilities of our products.
Below are the main roadmap details for functional areas inside ESP-IDF.
- New Chip Support
- Add the initial support for the mass production version of ESP32-C5 in ESP-IDF v5.5, refer to [ESP32-C5 Support Status](https://github.com/espressif/esp-idf/issues/14021)
- Add the initial support for the mass production version of ESP32-C61 in ESP-IDF v5.5, refer to [ESP32-C61 Support Status](https://developer.espressif.com/pages/chip-support-status/esp32c61/#esp-idf)
- Bugfix releases
- Do bugfix releases v5.0.8 and v5.0.9 and stop maintaining ESP-IDF v5.0 in May 2025
- Do bugfix releases v5.1.6 and v5.1.7 and stop maintaining ESP-IDF v5.1 in December 2025
- Release bugfix IDF v5.2.4, IDF v5.2.5 and IDF v5.2.6 in 2025, and push release/5.2 to maintenance period from February 2025
- Release bugfix IDF v5.3.3 and IDF v5.3.4 in 2025, and push release/5.3 to maintenance period from July 2025
- Do more bug fixes releases for release/5.4 (IDF v5.4.1, IDF v5.4.2, IDF v5.4.3) and release/5.5 (IDF v5.5.1, IDF v5.5.2), and push releases to be more stable and more production-ready
## ESP-IDF Planning information
For the full list of ESP-IDF releases, please visit https://github.com/espressif/esp-idf/releases
All the information provided here is subject to change without notice, due to business reasons and other factors.
Please refer to https://docs.espressif.com/projects/esp-idf/en/latest/esp32/versions.html#support-periods for more details on ESP-IDF supported versions and support period policy.
## Reporting a Vulnerability
Please refer to [Espressif Security Incident Response Process](https://www.espressif.com/sites/default/files/Espressif%20Security%20Incident%20Response%20Process%20v1.0_EN.pdf) on the guidelines to report a security vulnerability. Please do **NOT** create a public GitHub issue.
Each ESP-IDF major and minor release (V4.1, V4.2, etc) is supported for 30 months after the initial stable release date.
Each ESP-IDF major and minor release (V4.1, V4.2, etc) is supported for
30 months after the initial stable release date.
Supported means that the ESP-IDF team will continue to apply bug fixes, security fixes, etc to the release branch on GitHub, and periodically make new bugfix releases as needed.
Supported means that the ESP-IDF team will continue to apply bug fixes,
security fixes, etc to the release branch on GitHub, and periodically
make new bugfix releases as needed.
Support period is divided into "Service" and "Maintenance" period:
@@ -16,36 +19,58 @@ Support period is divided into "Service" and "Maintenance" period:
| Service | 12 months | Yes |
| Maintenance | 18 months | No |
During the Service period, bugfixes releases are more frequent. In some cases, support for new features may be added during the Service period (this is reserved for features which are needed to meet particular regulatory requirements or standards for new products, and which carry a very low risk of introducing regressions.)
During the Service period, bugfixes releases are more frequent. In some cases,
support for new features may be added during the Service period (this is
reserved for features which are needed to meet particular regulatory
requirements or standards for new products, and which carry a very low risk of
introducing regressions.)
During the Maintenance period, the version is still supported but only bugfixes for high severity issues or security issues will be applied.
During the Maintenance period, the version is still supported but only bugfixes
for high severity issues or security issues will be applied.
Using an “In Service” version is recommended when starting a new project.
Users are encouraged to upgrade all projects to a newer ESP-IDF release before the support period finishes and the release becomes End of Life (EOL). It is our policy to not continue fixing bugs in End of Life releases.
Users are encouraged to upgrade all projects to a newer ESP-IDF release before
the support period finishes and the release becomes End of Life (EOL). It is our
policy to not continue fixing bugs in End of Life releases.
Pre-release versions (betas, previews, `-rc` and `-dev` versions, etc) are not covered by any support period. Sometimes a particular feature is marked as "Preview" in a release, which means it is also not covered by the support period.
Pre-release versions (betas, previews, `-rc` and `-dev` versions, etc)
are not covered by any support period. Sometimes a particular feature is
marked as "Preview" in a release, which means it is also not covered
by the support period.
ESP-IDF should be used in an up-to-date software environment. The operating system and other third-party tools should be supported by their maintainers. ESP-IDF cannot keep compatibility with unsupported third-party tools.
ESP-IDF should be used in an up-to-date software environment. The operating system
and other third-party tools should be supported by their maintainers.
ESP-IDF cannot keep compatibility with unsupported third-party tools.
The ESP-IDF Programming Guide has information about the [different versions of ESP-IDF](https://docs.espressif.com/projects/esp-idf/en/latest/versions.html) (major, minor, bugfix, etc).
The ESP-IDF Programming Guide has information about the
[different versions of ESP-IDF](https://docs.espressif.com/projects/esp-idf/en/latest/versions.html)
(major, minor, bugfix, etc).
Example
-------
ESP-IDF V3.3 was released in September 2019. It was supported for 30 months until February 2022.
ESP-IDF V3.3 was released in September 2019. It will be supported for 30 months
until February 2022.
- The first V3.3 release was `v3.3` in September 2019.
- The ESP-IDF team continues to backport bug fixes, security fixes, etc to the release branch `release/v3.3`.
- Periodically stable bugfix releases are created from the release branch. For example `v3.3.1`, `v3.3.2`, etc. Users are encouraged to always update to the latest bugfix release.
-V3.3 bugfix releases continue until February 2022, when all V3.3.x releases become End of Life.
- The ESP-IDF team continues to backport bug fixes, security fixes,
etc to the release branch `release/v3.3`.
-Periodically stable bugfix releases are created from the release
branch. For example `v3.3.1`, `v3.3.2`, etc. Users are encouraged to
always update to the latest bugfix release.
- V3.3 bugfix releases continue until February 2022, when all V3.3.x
releases become End of Life.
Existing Releases
-----------------
ESP-IDF release V4.1 and all newer releases will follow this support period policy. The support period for each release will be announced when the release is made.
ESP-IDF release V4.1 and all newer releases will follow this support period
policy. The support period for each release will be announced when the release
is made.
For releases made before the current support period policy was announced, the original support periods apply:
For releases made before the current support period policy was announced, the
original support periods apply:
* ESP-IDF V4.0.x will be supported until October 2021
* ESP-IDF V3.3.x will be supported until February 2022
@@ -54,5 +79,8 @@ For releases made before the current support period policy was announced, the or
Policy History
--------------
* September 2019. This policy splits ESP-IDF releases into Standard and Long Term Support.
* July 2020. All releases from now will have the same support period, which is equal to the previous Long Term Support period. Added “In Service” period, during which versions will receive more updates.
* September 2019. This policy split ESP-IDF releases into Standard and Long Term
Support.
* July 2020. All releases from now will have the same support period, which is
equal to the previous Long Term Support period. Added “In Service” period,
@@ -8,9 +8,16 @@ This document contains details about what the core components are, what they con
The core components are organized into two groups.
The first group (referred to as `G0`) includes `hal`, `arch` (where `arch` is either `riscv` or `xtensa` depending on the chip), `esp_rom`, `esp_common`, and `soc`. This group contains information about and provides low-level access to the underlying hardware. In the case of `esp_common`, it contains hardware-agnostic code and utilities. These components may have dependencies on each other within the group, but outside dependencies should be minimized. The reason for this approach is that these components are fundamental, and many other components may require them. Ideally, the dependency relationship only goes one way, making it easier for this group to be usable in other projects.
The first group (referred to as `G0` from now on) contains `hal`, `xtensa` and `riscv` (referred to as `arch` components from now on), `esp_rom`, `esp_common`, and `soc`. This
group contain information about and low-level access to underlying hardware; or in the case of `esp_common`, hardware-agnostic code and utilities.
These components can depend on each other, but as much as possible have no dependencies outside the group. The reason for this is that, due to the
nature of what these components contain, the likelihood is high that a lot of other components will require these. Ideally, then, the dependency
relationship only goes one way. This makes it easier for these components, as a group, to be usable in another project. One can conceivably implement
a competing SDK to ESP-IDF on top of these components.
The second group (referred to as `G1`) operates at a higher level than the first group. `G1` includes the components `esp_hw_support`, `esp_system`, `esp_libc`, `spi_flash`,`freertos`, `log`, and `heap`. Like the first group, circular dependencies within this group are allowed, and these components can have dependencies on the first group. G1 components represent essential software mechanisms for building other components.
The second group (referred to as `G1` from now on) sits at a higher level than the first group. This group contains the components `esp_hw_support`, `esp_system`, `newlib`, `spi_flash`,
`freertos`, `log`, and `heap`. Like the first group, circular dependencies within the group are allowed; and being at a higher level, dependency on the first group
is allowed. These components represent software mechanisms essential to building other components.
## Descriptions
@@ -25,7 +32,7 @@ into routines that achieve a meaningful action or state of the peripheral.
Example:
-`spi_flash_ll_set_address` is a low-level function part of the hardware abstraction `spi_flash_hal_read_block`
-`spi_flash_ll_set_address` is a low-level function part of the hardware abstraction `spi_flash_hal_read_block`
#### `arch`
@@ -34,19 +41,19 @@ This can also contain files provided by the architecture vendor.
Example:
-`xt_set_exception_handler`
-`rv_utils_intr_enable`
-`ERI_PERFMON_MAX`
-`xt_set_exception_handler`
-`riscv_global_interrupts_enable`
-`ERI_PERFMON_MAX`
#### `esp_common`
Contains hardware-agnostic definitions, constants, macros, utilities, 'pure' and/or algorithmic functions that is usable by all other components (that is, barring there being a more appropriate component to put them in).
Contains hardware-agnostic definitions, constants, macros, utilities, 'pure' and/or algorithmic functions that is useable by all other components (that is, barring there being a more appropriate component to put them in).
Example:
-`BIT(nr)` and other bit manipulation utilities in the future
-`IDF_DEPRECATED(REASON)`
-`ESP_IDF_VERSION_MAJOR`
-`BIT(nr)` and other bit manipulation utilities in the future
-`IDF_DEPRECATED(REASON)`
-`ESP_IDF_VERSION_MAJOR`
#### `soc`
@@ -54,9 +61,9 @@ Contains description of the underlying hardware: register structure, addresses,
Example:
-`DR_REG_DPORT_BASE`
-`SOC_MCPWM_SUPPORTED`
-`uart_dev_s`
-`DR_REG_DPORT_BASE`
-`SOC_MCPWM_SUPPORTED`
-`uart_dev_s`
#### `esp_rom`
@@ -64,8 +71,8 @@ Contains headers, linker scripts, abstraction layer, patches, and other related
Example:
-`esp32.rom.eco3.ld`
-`rom/aes.h`
-`esp32.rom.eco3.ld`
-`rom/aes.h`
### `G1` Components
@@ -85,26 +92,14 @@ Logging library.
Heap implementation.
#### `esp_libc`
#### `newlib`
Some functions n the standard library are implemented here, especially those needing other `G1` components.
Example:
-`malloc` is implemented in terms of the component `heap`'s functions
-`gettimeofday` is implemented in terms of system time in `esp_system`
#### `esp_mm`
Memory management. Currently, this encompasses:
- Memory mapping for MMU supported memories
- Memory synchronisation via Cache
- Utils such as APIs to convert between virtual address and physical address
#### `esp_psram`
Contains implementation of PSRAM services
-`malloc` is implemented in terms of the component `heap`'s functions
-`gettimeofday` is implemented in terms of system time in `esp_system`
#### `esp_system`
@@ -112,10 +107,10 @@ Contains implementation of system services and controls system behavior. The imp
here may take hardware resources and/or decide on a hardware state needed for support of a system service/feature/mechanism.
Currently, this encompasses the following, but not limited to:
- Startup and initialization
- Panic and debug
- Reset and reset reason
- Task and interrupt watchdogs
- Startup and initialization
- Panic and debug
- Reset and reset reason
- Task and interrupt watchdogs
#### `esp_hw_support`
@@ -123,19 +118,19 @@ Contains implementations that provide hardware operations, arbitration, or resou
is used in the system. Unlike `esp_system`, implementations here do not decide on a hardware state or takes hardware resource, acting
merely as facilitator to hardware access. Currently, this encompasses the following, but not limited to:
// In general tracing goes in the following way. User application requests tracing module to send some data by calling esp_apptrace_buffer_get(),
// module allocates necessary buffer in current input trace block. Then user fills received buffer with data and calls esp_apptrace_buffer_put().
// When current input trace block is filled with app data it is exposed to host and the second block becomes input one and buffer filling restarts.
// While target application fills one TRAX block host reads another one via JTAG.
// This module also allows communication in the opposite direction: from host to target. As it was said ESP32 and host can access different TRAX blocks
// simultaneously, so while target writes trace data to one block host can write its own data (e.g. tracing commands) to another one then when
// blocks are switched host receives trace data and target receives data written by host application. Target user application can read host data
// by calling esp_apptrace_read() API.
// To control buffer switching and for other communication purposes this implementation uses some TRAX registers. It is safe since HW TRAX tracing
// can not be used along with application tracing feature so these registers are freely readable/writeable via JTAG from host and via ERI from ESP32 cores.
// Overhead of this implementation on target CPU is produced only by allocating/managing buffers and copying of data.
// On the host side special OpenOCD command must be used to read trace data.
// 2. TRAX Registers layout
// ========================
// This module uses two TRAX HW registers to communicate with host SW (OpenOCD).
// - Control register uses TRAX_DELAYCNT as storage. Only lower 24 bits of TRAX_DELAYCNT are writable. Control register has the following bitfields:
// 14..0 bits - actual length of user data in trace memory block. Target updates it every time it fills memory block and exposes it to host.
// Host writes zero to this field when it finishes reading exposed block;
// 21..15 bits - trace memory block transfer ID. Block counter. It can overflow. Updated by target, host should not modify it. Actually can be 2 bits;
// 22 bit - 'host data present' flag. If set to one there is data from host, otherwise - no host data;
// 23 bit - 'host connected' flag. If zero then host is not connected and tracing module works in post-mortem mode, otherwise in streaming mode;
// - Status register uses TRAX_TRIGGERPC as storage. If this register is not zero then current CPU is changing TRAX registers and
// this register holds address of the instruction which application will execute when it finishes with those registers modifications.
// See 'Targets Connection' setion for details.
// 3. Modes of operation
// =====================
// This module supports two modes of operation:
// - Post-mortem mode. This is the default mode. In this mode application tracing module does not check whether host has read all the data from block
// exposed to it and switches block in any case. The mode does not need host interaction for operation and so can be useful when only the latest
// trace data are necessary, e.g. for analyzing crashes. On panic the latest data from current input block are exposed to host and host can read them.
// It can happen that system panic occurs when there are very small amount of data which are not exposed to host yet (e.g. crash just after the
// TRAX block switch). In this case the previous 16KB of collected data will be dropped and host will see the latest, but very small piece of trace.
// It can be insufficient to diagnose the problem. To avoid such situations there is menuconfig option
// CONFIG_APPTRACE_POSTMORTEM_FLUSH_THRESH
// which controls the threshold for flushing data in case of panic.
// - Streaming mode. Tracing module enters this mode when host connects to target and sets respective bits in control registers (per core).
// In this mode before switching the block tracing module waits for the host to read all the data from the previously exposed block.
// On panic tracing module also waits (timeout is configured via menuconfig via CONFIG_APPTRACE_ONPANIC_HOST_FLUSH_TMO) for the host to read all data.
// 4. Communication Protocol
// =========================
// 4.1 Trace Memory Blocks
// -----------------------
// Communication is controlled via special register. Host periodically polls control register on each core to find out if there are any data available.
// When current input memory block is filled it is exposed to host and 'block_len' and 'block_id' fields are updated in the control register.
// Host reads new register value and according to it's value starts reading data from exposed block. Meanwhile target starts filling another trace block.
// When host finishes reading the block it clears 'block_len' field in control register indicating to the target that it is ready to accept the next one.
// If the host has some data to transfer to the target it writes them to trace memory block before clearing 'block_len' field. Then it sets
// 'host_data_present' bit and clears 'block_len' field in control register. Upon every block switch target checks 'host_data_present' bit and if it is set
// reads them to down buffer before writing any trace data to switched TRAX block.
// 4.2 User Data Chunks Level
// --------------------------
// Since trace memory block is shared between user data chunks and data copying is performed on behalf of the API user (in its normal context) in
// multithreading environment it can happen that task/ISR which copies data is preempted by another high prio task/ISR. So it is possible situation
// that task/ISR will fail to complete filling its data chunk before the whole trace block is exposed to the host. To handle such conditions tracing
// module prepends all user data chunks with header which contains allocated buffer size and actual data length within it. OpenOCD command
// which reads application traces reports error when it reads incomplete user data block.
// Data which are transffered from host to target are also prepended with a header. Down channel data header is simple and consists of one two bytes field
// containing length of host data following the header.
// 4.3 Data Buffering
// ------------------
// It takes some time for the host to read TRAX memory block via JTAG. In streaming mode it can happen that target has filled its TRAX block, but host
// has not completed reading of the previous one yet. So in this case time critical tracing calls (which can not be delayed for too long time due to
// the lack of free memory in TRAX block) can be dropped. To avoid such scenarios tracing module implements data buffering. Buffered data will be sent
// to the host later when TRAX block switch occurs. The maximum size of the buffered data is controlled by menuconfig option
// CONFIG_APPTRACE_PENDING_DATA_SIZE_MAX.
// 4.4 Target Connection/Disconnection
// -----------------------------------
// When host is going to start tracing in streaming mode it needs to put both ESP32 cores into initial state when 'host connected' bit is set
// on both cores. To accomplish this host halts both cores and sets this bit in TRAX registers. But target code can be halted in state when it has read control
// register but has not updated its value. To handle such situations target code indicates to the host that it is updating control register by writing
// non-zero value to status register. Actually it writes address of the instruction which it will execute when it finishes with
// the registers update. When target is halted during control register update host sets breakpoint at the address from status register and resumes CPU.
// After target code finishes with register update it is halted on breakpoint, host detects it and safely sets 'host connected' bit. When both cores
// are set up they are resumed. Tracing starts without further intrusion into CPUs work.
// When host is going to stop tracing in streaming mode it needs to disconnect targets. Disconnection process is done using the same algorithm
// as for connecting, but 'host connected' bits are cleared on ESP32 cores.
// 5. Module Access Synchronization
// ================================
// Access to internal module's data is synchronized with custom mutex. Mutex is a wrapper for portMUX_TYPE and uses almost the same sync mechanism as in
// vPortCPUAcquireMutex/vPortCPUReleaseMutex. The mechanism uses S32C1I Xtensa instruction to implement exclusive access to module's data from tasks and
// ISRs running on both cores. Also custom mutex allows specifying timeout for locking operation. Locking routine checks underlaying mutex in cycle until
// it gets its ownership or timeout expires. The differences of application tracing module's mutex implementation from vPortCPUAcquireMutex/vPortCPUReleaseMutex are:
// - Support for timeouts.
// - Local IRQs for CPU which owns the mutex are disabled till the call to unlocking routine. This is made to avoid possible task's prio inversion.
// When low prio task takes mutex and enables local IRQs gets preempted by high prio task which in its turn can try to acquire mutex using infinite timeout.
// So no local task switch occurs when mutex is locked. But this does not apply to tasks on another CPU.
// WARNING: Priority inversion can happen when low prio task works on one CPU and medium and high prio tasks work on another.
// WARNING: Care must be taken when selecting timeout values for trace calls from ISRs. Tracing module does not care about watchdogs when waiting
// on internal locks and for host to complete previous block reading, so if timeout value exceeds watchdog's one it can lead to the system reboot.
// 6. Timeouts
// ===========
// Timeout mechanism is based on xthal_get_ccount() routine and supports timeout values in microseconds.
// There are two situations when task/ISR can be delayed by tracing API call. Timeout mechanism takes into account both conditions:
// - Trace data are locked by another task/ISR. When wating on trace data lock.
// - Current TRAX memory input block is full when working in streaming mode (host is connected). When waiting for host to complete previous block reading.
// When wating for any of above conditions xthal_get_ccount() is called periodically to calculate time elapsed from trace API routine entry. When elapsed
// time exceeds specified timeout value operation is canceled and ESP_ERR_TIMEOUT code is returned.
// In general tracing goes in the following way. User application requests tracing module to send some data by calling esp_apptrace_buffer_get(),
// module allocates necessary buffer in current input trace block. Then user fills received buffer with data and calls esp_apptrace_buffer_put().
// When current input trace block is filled with app data it is exposed to host and the second block becomes input one and buffer filling restarts.
// While target application fills one TRAX block host reads another one via JTAG.
// This module also allows communication in the opposite direction: from host to target. As it was said ESP32 and host can access different TRAX blocks
// simultaneously, so while target writes trace data to one block host can write its own data (e.g. tracing commands) to another one then when
// blocks are switched host receives trace data and target receives data written by host application. Target user application can read host data
// by calling esp_apptrace_read() API.
// To control buffer switching and for other communication purposes this implementation uses some TRAX registers. It is safe since HW TRAX tracing
// can not be used along with application tracing feature so these registers are freely readable/writeable via JTAG from host and via ERI from ESP32 cores.
// Overhead of this implementation on target CPU is produced only by allocating/managing buffers and copying of data.
// On the host side special OpenOCD command must be used to read trace data.
// 2. TRAX Registers layout
// ========================
// This module uses two TRAX HW registers and one Performance Monitor register to communicate with host SW (OpenOCD).
// - Control register uses TRAX_DELAYCNT as storage. Only lower 24 bits of TRAX_DELAYCNT are writable. Control register has the following bitfields:
// CRC indicator (0xA55A) is used to distinguish valid CRC values from other data that might be in the register.
// CRC16 is calculated over the entire exposed block and is updated every time a block is exposed to the host.
// This allows the host to verify data integrity of the received trace data.
// 3. Modes of operation
// =====================
// This module supports two modes of operation:
// - Post-mortem mode. This is the default mode. In this mode application tracing module does not check whether host has read all the data from block
// exposed to it and switches block in any case. The mode does not need host interaction for operation and so can be useful when only the latest
// trace data are necessary, e.g. for analyzing crashes. On panic the latest data from current input block are exposed to host and host can read them.
// It can happen that system panic occurs when there are very small amount of data which are not exposed to host yet (e.g. crash just after the
// TRAX block switch). In this case the previous 16KB of collected data will be dropped and host will see the latest, but very small piece of trace.
// It can be insufficient to diagnose the problem. To avoid such situations there is menuconfig option
// CONFIG_APPTRACE_POSTMORTEM_FLUSH_THRESH
// which controls the threshold for flushing data in case of panic.
// - Streaming mode. Tracing module enters this mode when host connects to target and sets respective bits in control registers (per core).
// In this mode before switching the block tracing module waits for the host to read all the data from the previously exposed block.
// On panic tracing module also waits (timeout is configured via menuconfig via CONFIG_APPTRACE_ONPANIC_HOST_FLUSH_TMO) for the host to read all data.
// 4. Communication Protocol
// =========================
// 4.1 Trace Memory Blocks
// -----------------------
// Communication is controlled via special register. Host periodically polls control register on each core to find out if there are any data available.
// When current input memory block is filled it is exposed to host and 'block_len' and 'block_id' fields are updated in the control register.
// Host reads new register value and according to it's value starts reading data from exposed block. Meanwhile target starts filling another trace block.
// When host finishes reading the block it clears 'block_len' field in control register indicating to the target that it is ready to accept the next one.
// If the host has some data to transfer to the target it writes them to trace memory block before clearing 'block_len' field. Then it sets
// 'host_data_present' bit and clears 'block_len' field in control register. Upon every block switch target checks 'host_data_present' bit and if it is set
// reads them to down buffer before writing any trace data to switched TRAX block.
// 4.2 User Data Chunks Level
// --------------------------
// Since trace memory block is shared between user data chunks and data copying is performed on behalf of the API user (in its normal context) in
// multithreading environment it can happen that task/ISR which copies data is preempted by another high prio task/ISR. So it is possible situation
// that task/ISR will fail to complete filling its data chunk before the whole trace block is exposed to the host. To handle such conditions tracing
// module prepends all user data chunks with header which contains allocated buffer size and actual data length within it. OpenOCD command
// which reads application traces reports error when it reads incomplete user data block.
// Data which are transffered from host to target are also prepended with a header. Down channel data header is simple and consists of one two bytes field
// containing length of host data following the header.
// 4.3 Target Connection/Disconnection
// -----------------------------------
// When host is going to start tracing in streaming mode it needs to put both ESP32 cores into initial state when 'host connected' bit is set
// on both cores. To accomplish this host halts both cores and sets this bit in TRAX registers. But target code can be halted in state when it has read control
// register but has not updated its value. To handle such situations target code indicates to the host that it is updating control register by writing
// non-zero value to status register. Actually it writes address of the instruction which it will execute when it finishes with
// the registers update. When target is halted during control register update host sets breakpoint at the address from status register and resumes CPU.
// After target code finishes with register update it is halted on breakpoint, host detects it and safely sets 'host connected' bit. When both cores
// are set up they are resumed. Tracing starts without further intrusion into CPUs work.
// When host is going to stop tracing in streaming mode it needs to disconnect targets. Disconnection process is done using the same algorithm
// as for connecting, but 'host connected' bits are cleared on ESP32 cores.
// 5. Module Access Synchronization
// ================================
// Access to internal module's data is synchronized with custom mutex. Mutex is a wrapper for portMUX_TYPE and uses almost the same sync mechanism as in
// vPortCPUAcquireMutex/vPortCPUReleaseMutex. The mechanism uses S32C1I Xtensa instruction to implement exclusive access to module's data from tasks and
// ISRs running on both cores. Also custom mutex allows specifying timeout for locking operation. Locking routine checks underlying mutex in cycle until
// it gets its ownership or timeout expires. The differences of application tracing module's mutex implementation from vPortCPUAcquireMutex/vPortCPUReleaseMutex are:
// - Support for timeouts.
// - Local IRQs for CPU which owns the mutex are disabled till the call to unlocking routine. This is made to avoid possible task's prio inversion.
// When low prio task takes mutex and enables local IRQs gets preempted by high prio task which in its turn can try to acquire mutex using infinite timeout.
// So no local task switch occurs when mutex is locked. But this does not apply to tasks on another CPU.
// WARNING: Priority inversion can happen when low prio task works on one CPU and medium and high prio tasks work on another.
// WARNING: Care must be taken when selecting timeout values for trace calls from ISRs. Tracing module does not care about watchdogs when waiting
// on internal locks and for host to complete previous block reading, so if timeout value exceeds watchdog's one it can lead to the system reboot.
// 6. Timeouts
// ===========
// Timeout mechanism is based on xthal_get_ccount() routine and supports timeout values in microseconds.
// There are two situations when task/ISR can be delayed by tracing API call. Timeout mechanism takes into account both conditions:
// - Trace data are locked by another task/ISR. When waiting on trace data lock.
// - Current TRAX memory input block is full when working in streaming mode (host is connected). When waiting for host to complete previous block reading.
// When waiting for any of above conditions xthal_get_ccount() is called periodically to calculate time elapsed from trace API routine entry. When elapsed
// time exceeds specified timeout value operation is canceled and ESP_ERR_TIMEOUT code is returned.
#define SEGGER_SYSVIEW_ID_BASE SOC_DROM_LOW // Default value for the lowest Id reported by the application. Can be overridden by the application via SEGGER_SYSVIEW_SetRAMBase(). (i.e. 0x20000000 when all Ids are an address in this RAM)
#define SEGGER_SYSVIEW_ID_SHIFT 0 // Number of bits to shift the Id to save bandwidth. (i.e. 2 when Ids are 4 byte aligned)
#define SEGGER_SYSVIEW_GET_INTERRUPT_ID() ((*(U32 *)(0xE000ED04)) & 0x1FF) // Get the currently active interrupt Id. (i.e. read Cortex-M ICSR[8:0] = active vector)
#define SEGGER_SYSVIEW_GET_INTERRUPT_ID() (__get_IPSR()) // Workaround for IAR, which might do a byte-access to 0xE000ED04. Read IPSR instead.
#else
#define SEGGER_SYSVIEW_GET_INTERRUPT_ID() ((*(U32 *)(0xE000ED04)) & 0x3F) // Get the currently active interrupt Id. (i.e. read Cortex-M ICSR[5:0] = active vector)
#endif
#else
#define SEGGER_SYSVIEW_GET_INTERRUPT_ID() SEGGER_SYSVIEW_X_GetInterruptId() // Get the currently active interrupt Id from the user-provided function.
@@ -119,29 +110,6 @@ extern "C" { /* Make sure we have C-declarations in C++ programs */
#define SEGGER_MIN(a,b) (((a) < (b)) ? (a) : (b))
#define SEGGER_MAX(a,b) (((a) > (b)) ? (a) : (b))
#ifndef SEGGER_USE_PARA // Some compiler complain about unused parameters.
#define SEGGER_USE_PARA(Para) (void)Para // This works for most compilers.
#endif
#define SEGGER_ADDR2PTR(Type, Addr) (/*lint -e(923) -e(9078)*/((Type*)((PTR_ADDR)(Addr)))) // Allow cast from address to pointer.
#define SEGGER_PTR2ADDR(p) (/*lint -e(923) -e(9078)*/((PTR_ADDR)(p))) // Allow cast from pointer to address.
#define SEGGER_PTR2PTR(Type, p) (/*lint -e(740) -e(826) -e(9079) -e(9087)*/((Type*)(p))) // Allow cast from one pointer type to another (ignore different size).
SEGGER_BUFFER_DESC*pBufferDesc;// Buffer descriptor to use for output.
void(*pfFlush)(SEGGER_SNPRINTF_CONTEXT*pContext);// Callback executed once the buffer is full. Callback decides if the buffer gets cleared to store more or not.
unsignedSizeOfBuffer;// Buffer size in bytes. Note that one byte is lost, as this implementation does not fill up the buffer in order to avoid the problem of being unable to distinguish between full and empty.
unsignedWrOff;// Position of next item to be written by either target.
volatileunsignedRdOff;// Position of next item to be read by host. Must be volatile since it may be modified by host.
unsignedFlags;// Contains configuration flags. Flags[31:24] are used for validity check and must be zero. Flags[23:2] are reserved for future use. Flags[1:0] = RTT operating mode.
unsignedFlags;// Contains configuration flags
}SEGGER_RTT_BUFFER_UP;
//
@@ -337,7 +106,7 @@ typedef struct {
unsignedSizeOfBuffer;// Buffer size in bytes. Note that one byte is lost, as this implementation does not fill up the buffer in order to avoid the problem of being unable to distinguish between full and empty.
volatileunsignedWrOff;// Position of next item to be written by host. Must be volatile since it may be modified by host.
unsignedRdOff;// Position of next item to be read by target (down-buffer).
unsignedFlags;// Contains configuration flags. Flags[31:24] are used for validity check and must be zero. Flags[23:2] are reserved for future use. Flags[1:0] = RTT operating mode.
unsignedFlags;// Contains configuration flags
}SEGGER_RTT_BUFFER_DOWN;
//
@@ -351,9 +120,6 @@ typedef struct {
intMaxNumDownBuffers;// Initialized to SEGGER_RTT_MAX_NUM_DOWN_BUFFERS (type. 2)
SEGGER_RTT_BUFFER_UPaUp[SEGGER_RTT_MAX_NUM_UP_BUFFERS];// Up buffers, transferring information up from target via debug probe to host
SEGGER_RTT_BUFFER_DOWNaDown[SEGGER_RTT_MAX_NUM_DOWN_BUFFERS];// Down buffers, transferring information down from host via debug probe to target
#define SEGGER_RTT_HASDATA_UP(n) (((SEGGER_RTT_BUFFER_UP*)((uintptr_t)&_SEGGER_RTT.aUp[n] + SEGGER_RTT_UNCACHED_OFF))->WrOff - ((SEGGER_RTT_BUFFER_UP*)((uintptr_t)&_SEGGER_RTT.aUp[n] + SEGGER_RTT_UNCACHED_OFF))->RdOff) // Access uncached to make sure we see changes made by the J-Link side and all of our changes go into HW directly
#define SEGGER_SYSVIEW_INFO_SIZE 9 // Minimum size, which has to be reserved for a packet. 1-2 byte of message type, 0-2 byte of payload length, 1-5 bytes of timestamp.
#define SEGGER_SYSVIEW_QUANTA_U32 5 // Maximum number of bytes to encode a U32, should be reserved for each 32-bit value in a packet.
#define SEGGER_SYSVIEW_GET_INTERRUPT_ID() ((*(U32*)(0xE000ED04)) & 0x1FF) // Get the currently active interrupt Id. (i.e. read Cortex-M ICSR[8:0] = active vector)
#define SEGGER_SYSVIEW_GET_INTERRUPT_ID() (__get_IPSR()) // Workaround for IAR, which might do a byte-access to 0xE000ED04. Read IPSR instead.
#else
#define SEGGER_SYSVIEW_GET_INTERRUPT_ID() ((*(U32*)(0xE000ED04)) & 0x3F) // Older versions of IAR do not include __get_IPSR, but might also not optimize to byte-access.
#endif
#else
#define SEGGER_SYSVIEW_GET_INTERRUPT_ID() ((*(U32*)(0xE000ED04)) & 0x3F) // Get the currently active interrupt Id. (i.e. read Cortex-M ICSR[5:0] = active vector)
#endif
#else
#define SEGGER_SYSVIEW_GET_INTERRUPT_ID() SEGGER_SYSVIEW_X_GetInterruptId() // Get the currently active interrupt Id from the user-provided function.
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.