wear levelling
This MR adds wear levelling component. It presents an interface similar to the interface of spi_flash and esp_partition. Inside, it stores data inside a partition to in a way that reduces worst case number of erase cycles for any given sector.
Also included are APIs similar to the ones provided for SDMMC to mount FAT filesystem on top of the wear levelling partition. A simple example shows how this API can be used.
Ref TW10338.
See merge request !567
lwip: fix error when building on OS X, only build ppp if enabled
- reorder directories listed in COMPONENT_SRCDIRS so that
subdirectories precede parent directories
- don’t include PPP source directories if PPP support is not enabled
See merge request !700
- reorder directories listed in COMPONENT_SRCDIRS so that
subdirectories precede parent directories
- don’t include PPP source directories if PPP support is not enabled
XTAL frequency detection, support for selecting XTAL frequency
This MR adds more robust XTAL frequency detection code (which gets run in the bootloader) and an option to set XTAL frequency in Kconfig. By default we still use autodetection, since it is more reliable than the one used in ROM code.
This will help with issues about XTAL frequency detection in high ambient temperature conditions.
Ref TW12008
See merge request !694
sdmmc: handle card removal when CD is not used
When SD card is removed during transaction, SDMMC peripheral can report
a range of errors, such as timeouts, CRC errors, start/end bit errors.
Under normal conditions (card is inserted), SDMMC peripheral also generates
command done or data done interrupts. When the card is removed, such
interrupts may not be always generated.
This change fixes handling of timeout interrupts and SBE interrupts.
It also adds a one second timeout into the event processing loop. This
timeout allows applications to recover in cases when the SDMMC peripheral
doesn’t generate command/data done event on card removal.
Fixes TW11592.
See merge request !678
fat/sdmmc: unmount FATFS object on error
Failure to call f_mount(NULL,...) makes FATFS attempt to clean up the old
FS object upon next mount. If previous mount operation has failed, some
parts of FS object may not be fully initialized, which will cause errors
(such as attempting to delete a mutex which wasn’t allocated).
Fixes TW11594.
See merge request !679
ROM code already implements XTAL frequency detection, but it uses the 8M
clock before the clock tuning parameters are initialized. With the
zero clock tuning parameter, 8M clock has significant frequency deviation
at high temperatures, which can lead to erroneous detection of 40 MHz
crystal as a 26 MHz one.
This change adds XTAL frequency detection code to rtc_clk_init routine,
and detection is performed after the 8M clock tuning parameter as been
initialized.
Fix device_name check in gatt_client example
`strcmp` was used against `adv_name` array, which was not a zero terminated string, causing `strcmp` check to fail for valid names.
Ref. https://github.com/espressif/esp-idf/pull/502
See merge request !652
lwip: fix tcp stable test abort issue
This MR covers following changes:
1. Modify dhcp server timer to 1 seconds
2. Enable ETHARP_TRUST_IP_MAC. Consider following scenario: we are in throughput test or traffic stability test, if this option is disabled, then every 5 minutes, the IP/MAC entry in arch cache is aged out, however, the traffic continuously send to lwip from application, because there is no IP/MAC entry in ARP cache, then the packets have to be buffered in ARP queue and a ARP request is triggered, but the ARP queue can only holds 3 packets, the later packets will be dropped, then if the traffic is big, a lot of packets will be dropped here before we get the right ARP response. For TCP, this will trigger re-transmit, it's intolerable for some application, such as real time audio, if re-transmit happen, then performance of voice will be impact. For UDP, sometimes it may also cause problem, such as DHCP, if here we failed to send the DHCP here, we has to wait the DHCP timeout etc... so this option is enabled here by default.
See merge request !681
esp32: update wifi lib for limitting dynamic wifi buffer
Add limit for all dynamic wifi ebuf to avoid wifi run out of memory in some extreme scanrio.
The default max allocated dynamic tx buffer is 32
The default max allocated dynamic rx buffer is 64, make default value is bigger because when all packets we received are small packets, e.g. the length is 64Bytes, then 64K can hold 1000 packets, so 64 maybe a good candidate default value, anyway the customer can configure it via menuconfig.
The default dynamic wifi internal long/long-long mgmt is 32, generally 32 is enough for mgmt packet (beacon/auth/assoc/probe/null etc). Generally when all the 32 mgmt buffer is run out of memory, it means internal wifi state machine may has problem, we need to debug it.
See merge request !683
There are some RODATAs of libphy.a that are called in ISR. So need
to put them into DRAM to avoid access them when R/W SPI flash. Due
to the RODATAs which are called in ISR haven't been picked out to
put into DRAM, put all of the RODATA of libphy.a into DRAM. This
will be optimized in the future.
esp32: Added dumping debug info from traceport upon reset by any WDT
Adds ability to dump debug info (PC and internal processor state) from traceport upon reset by any WDT.
See merge request !654
soc: allow REG_SET_FIELD to be used for bit fields
- Fixes an issue with `rtc_clk_apll_enable`: https://esp32.com/viewtopic.php?f=13&t=1673
- Fixes `rtc_clk_fast_freq_set` function always selecting XTAL/4 as fast clock source.
- Fixes regression in deep sleep current (7uA instead of 5uA).
See merge request !674
rtc_clk_init: handle case when XTAL frequency has already been set
On first reset, ROM code writes the estimated XTAL frequency into
RTC_APB_FREQ_REG (aka STORE5). If the application doesn’t specify exact
XTAL frequency (which is always the case for now), rtc_clk_init will
guess what kind of XTAL is used (26M or 40M), based on the estimated
frequency. Later, detected frequency is written into RTC_XTAL_FREQ_REG
(aka STORE4).
When the application switches clock source to PLL, APB frequency changes
and RTC_APB_FREQ_REG is updated. If the application encounters an RTC
WDT reset, RTC_APB_FREQ_REG will not be updated prior to reset. Once the
application starts up again, it will attempt to auto-detect XTAL
frequency based on RTC_APB_FREQ_REG, which now has value of 80000000.
This will fail, and rtc_clk_xtal_freq_estimate will fall back to the
default value of 26 MHz. Due to an incorrect XTAL frequency, PLL
initialization will also take incorrect path, and PLL will run at a
different frequency. Depending on the application this may cause just
garbage output on UART or a crash (if WiFi is used).
This change checks if RTC_XTAL_FREQ_REG has already been set before trying
to estimate XTAL frequency based on the value of RTC_APB_FREQ_REG, and
uses RTC_XTAL_FREQ_REG value if it is valid.
Fixes TW11738.
See merge request !691
Base MAC address can be stored in default manufacture-defined or customer
pre-defined place in EFUSE and other place e.g. flash or EEPROM.
If choose to use base MAC address which is stored in other place, please
call esp_base_mac_addr_set_external() before initializing WiFi/BT/Ehternet.
mbedtls port: Fix detection of EWOULDBLOCK/EAGAIN with non-blocking sockets
Since mbedtls_net_errno is reset by fcntl, it is reset after calling
net_would_block, so the call to mbedtls_net_errno in mbedtls_net_recv
and mbedtls_net_send will always get back 0. This change propagates
the value returned by mbedtls_net_errno up through net_would_block,
to allow the correct error value to be used and avoid a redundant
call to mbedtls_net_errno.
Merges PR #511https://github.com/espressif/esp-idf/pull/511
See merge request !688
On first reset, ROM code writes the estimated XTAL frequency into
RTC_APB_FREQ_REG (aka STORE5). If the application doesn’t specify exact
XTAL frequency (which is always the case for now), rtc_clk_init will
guess what kind of XTAL is used (26M or 40M), based on the estimated
frequency. Later, detected frequency is written into RTC_XTAL_FREQ_REG
(aka STORE4).
When the application switches clock source to PLL, APB frequency changes
and RTC_APB_FREQ_REG is updated. If the application encounters an RTC
WDT reset, RTC_APB_FREQ_REG will not be updated prior to reset. Once the
application starts up again, it will attempt to auto-detect XTAL
frequency based on RTC_APB_FREQ_REG, which now has value of 80000000.
This will fail, and rtc_clk_xtal_freq_estimate will fall back to the
default value of 26 MHz. Due to an incorrect XTAL frequency, PLL
initialization will also take incorrect path, and PLL will run at a
different frequency. Depending on the application this may cause just
garbage output on UART or a crash (if WiFi is used).
For example,
SRCDIRS = comp_a happy/comp_b /c/dev/comp_c
Then the following are built:
build/comp_a/libcomp_a.a
build/comp_b/libcomp_b.a
build/comp_c/libcomp_c.a
But when LD is run the -L is calculated as follows
-L build/comp_a
-L build/happy/comp_b
-L build//c/dev/comp_c
This means comp_b and comp_c are not found by LD. With this change set -L is calculated correctly for comp_b and comp_c
Merges #504https://github.com/espressif/esp-idf/pull/504
SPI transfer length is bits, not bytes, so the error should indicate bits. Also, there are separate lengths for rx and
tx (confusingly named rxlength and length... if rxlength is 0, length is used). The code checks the tx length for the
rx, so it never validates rxlength.
Originally contributed as part of #511https://github.com/espressif/esp-idf/pull/511
Since mbedtls_net_errno is reset by fcntl, it is reset after calling
net_would_block, so the call to mbedtls_net_errno in mbedtls_net_recv
and mbedtls_net_send will always get back 0. This change propagates
the value returned by mbedtls_net_errno up through net_would_block,
to allow the correct error value to be used and avoid a redundant
call to mbedtls_net_errno.
Merges PR #511https://github.com/espressif/esp-idf/pull/511
Failure to call f_mount(NULL,...) makes FATFS attempt to clean up the old
FS object upon next mount. If previous mount operation has failed, some
parts of FS object may not be fully initialized, which will cause errors
(such as attempting to delete a mutex which wasn’t allocated).
