Replace the two separate volatile counters (s_idle_ticks, s_busy_ticks)
with a two-element array s_ticks[2]:
[0] = idle ticks (xTaskGetCurrentTaskHandle() != s_idle_handle → false → 0)
[1] = busy ticks (xTaskGetCurrentTaskHandle() != s_idle_handle → true → 1)
The tick hook becomes a single branchless statement:
s_ticks[xTaskGetCurrentTaskHandle() != s_idle_handle]++;
This eliminates the conditional branch from the tick ISR at the cost
of a few additional instructions in IRAM. On Xtensa LX7 the branch
is somewhat unpredictable — the system alternates between idle and
busy — so removing the misprediction penalty (~5–10 cycles/call)
outweighs the slightly larger code size.
_onSample() is updated to read s_ticks[0] (idle) and s_ticks[1]
(busy) accordingly. All other logic is unchanged.
Previously _onSample() computed and stored a volatile float _sma_avg
on every sample (64 times/minute on core 0). The getter simply returned
that pre-computed value.
This commit inverts the responsibility:
- _sma_sum is now volatile uint16_t — the raw integer sum is the
cross-core shared state, written atomically by core 0 (single S16I
instruction on Xtensa LX7) and read by core 1.
- The float conversion (uint16_t → float multiply) is moved into
getCore0Util(), which is called rarely (once/minute for history,
on-demand for web requests). The multiply now happens on the core
that actually needs the result.
- _sma_avg is removed entirely, saving 4 bytes and one volatile float
store per sample from the hot path.
- The SMA update is rewritten as a single combined expression:
const uint16_t last = _sma_buf[_sma_idx];
_sma_buf[_sma_idx] = s8;
_sma_sum = (_sma_sum - last) + s8;
This produces a single write to _sma_sum instead of two (decrement
then increment), which is cleaner when _sma_sum is volatile.
The cross-core contract is unchanged: core 0 writes _sma_sum once per
sample; core 1 reads it in getCore0Util(). A 16-bit aligned store on
Xtensa LX7 is a single instruction, so no spinlock is needed.
The previous implementation maintained three exponential moving averages
(1/5/15-minute) of CPU busy-fraction, sampled every 5 seconds. This had
two problems:
1. Wrong semantics: the metric was labelled "load_avg" (a Unix concept
measuring run-queue depth), but the tracker actually measures CPU
busy-time as a fraction of FreeRTOS ticks — i.e. utilization, not
load. The name was misleading.
2. Poor responsiveness: the 1-minute EMA (DECAY = exp(-5/60) ≈ 0.920)
has a ~60-second time constant. On a live web panel, this made the
metric appear frozen, especially during short bursts of activity
(e.g. an HTTP request from the panel itself).
This commit replaces the EMA with a 64-sample simple moving average
(SMA) over a compact uint8_t circular buffer. The sample interval is
60 s / 64 = 937,500 µs, so the window covers exactly 60 seconds:
Algorithm:
- Every 937,500 µs (= 60 s / 64), the FreeRTOS tick delta (busy vs
idle ticks on core 0) is computed and stored as a uint8_t
(0–255 = 0–100% utilization).
- The circular buffer holds 64 samples, spanning exactly 60 seconds
(64 × 937,500 µs = 60,000,000 µs). The timer interval is derived
directly from the window size: 60 000 000 / SMA_WINDOW µs.
- The index wraps with a bitwise AND (& 63) instead of modulo, since
64 is a power of 2.
- The running sum is a uint16_t (max 64 × 255 = 16 320, fits easily).
- The result _sma_avg is a volatile float written atomically by the
esp_timer task (core 0) and read from the main loop (core 1).
No spinlock is needed: on Xtensa LX7, a 32-bit aligned float store
is a single instruction.
The 60-second window smooths out short bursts (e.g. WiFi/HTTP spikes)
while reacting to sustained load changes within ~10–15 seconds.
Naming:
- The public API is now getCore0Util() returning a float in [0.0, 1.0].
The name explicitly identifies which core is measured (core 0, which
runs WiFi, MQTT, HTTP, and LwIP — see task_pinning.c).
- JSON keys: "load_avg" (array) → "core0_util" (scalar float, percent)
- HistorySample field: load_avg1_pct → core0_util_pct
- StatsHistory series key: "cpu_load" → "core0_util"
- Web panel label: "Load Avg" → "Core0 Util"
The history snapshot (once per minute) reads the same _sma_avg value,
which at that point represents the rolling average of the last 60
seconds — exactly one history interval.
Track CPU utilisation on core 0 using a FreeRTOS tick hook that
increments per-tick idle/busy counters, sampled every 5s by an
esp_timer callback. Exponential moving averages with Linux-style
time constants (1 / 5 / 15 min) are maintained in software:
DECAY1 = exp(-5/60) ≈ 0.9200 (1-minute window)
DECAY5 = exp(-5/300) ≈ 0.9835 (5-minute window)
DECAY15 = exp(-5/900) ≈ 0.9945 (15-minute window)
Core 1 is excluded intentionally: it runs the Arduino loopTask at
100% load for LoRa packet processing, so its figure is always 1.0
and carries no diagnostic value. All other tasks are pinned to
core 0 by task_pinning.c, so core-0 load reflects the true system
utilisation.
New files:
arch/esp32/CPUUsageTracker.h – class declaration
arch/esp32/CPUUsageTracker.cpp – tick hook + esp_timer sampling
Integration:
MyMesh::begin() calls _cpu_tracker.begin() on ESP32 builds.
formatStatsReply() emits "load_avg":[<1m>,<5m>,<15m>] in the
compact stats JSON payload.
formatWebStatsSummaryJson() adds the same field to the web-panel
stats endpoint under core.load_avg.
The web-panel HUD gains a "Load Avg" metric tile showing all
three values side-by-side; the core-metrics grid is widened from
4 to 5 columns. The tile is rendered conditionally so older
firmware (or non-ESP32 builds) that omit the field degrade
gracefully.
CPUUsageTracker.cpp is added to the esp32_base build_src_filter
in platformio.ini.
Browsers negotiate ECDHE cipher suites by default. On ESP32-S3 the
hardware RSA accelerator handles RSA key exchange efficiently, but
there is no ECP hardware accelerator. ECDHE requires the server to
compute an ephemeral key pair: ecp_precompute_comb() builds a comb
table through many sequential ECP point doublings, each dispatched
to the hardware bignum unit (esp_bignum.c), but the ECP layer has
no RTOS yield points between iterations. The entire computation runs
to completion on CPU 0 without ever resetting the task watchdog.
A single handshake does not exceed the watchdog timeout on its own,
but two consecutive handshakes (e.g. a browser retry after a failed
attempt) accumulate enough uninterrupted runtime to starve IDLE0:
E (54924) esp-tls-mbedtls: mbedtls_ssl_handshake returned -0x0050
E (57208) esp-tls-mbedtls: mbedtls_ssl_handshake returned -0x7280
E (57638) task_wdt: Task watchdog got triggered.
E (57638) task_wdt: - IDLE0 (CPU 0)
E (57638) task_wdt: Tasks currently running:
E (57638) task_wdt: CPU 0: httpd
The crash occurs in ecp_precompute_comb() → ecp_double_jac() →
mbedtls_mpi_mul_mpi() during the ServerKeyExchange step.
Fix by wrapping mbedtls_ssl_config_defaults() via the linker --wrap
mechanism. The wrapper intercepts server-side SSL config init
(MBEDTLS_SSL_IS_SERVER) and replaces the cipher suite list with
RSA key exchange only, routing handshakes through the hardware RSA
accelerator and eliminating the ECDH path entirely. MQTT connections
(MBEDTLS_SSL_IS_CLIENT) are unaffected.
Also switch the self-signed cert generator from EC (prime256v1) to
RSA 2048 so the generated certificate matches the restricted cipher
suites.
Changes:
- arch/esp32/tls_cipher_restrict.c: new file implementing the
mbedtls_ssl_config_defaults wrap; restricts server cipher suites
to RSA_WITH_AES_{128,256}_{GCM,CBC}_SHA{256,384}
- platformio.ini: add -Wl,--wrap=mbedtls_ssl_config_defaults and
include tls_cipher_restrict.c in the esp32_base build
- arch/esp32/extra_scripts/generate_web_panel_cert.py: switch key
generation from `openssl ecparam -name prime256v1` to `openssl
genrsa 2048`
On dual-core ESP32-S3 (ARDUINO_RUNNING_CORE=1), the Arduino loop and
LoRa processing run exclusively on core 1. ESP-IDF v4 creates mqtt_task
with tskNO_AFFINITY, meaning FreeRTOS may schedule them on core 1 under
load, preempting the LoRa loop.
ESP-IDF v4 provides no public API to change a task's core affinity after
creation (vTaskCoreAffinitySet is IDF v5+ only), and the esp_mqtt_client
config struct has no task_core_id field. The precompiled Arduino-ESP32
framework cannot be patched via sdkconfig.
Instead, use the GCC/LD --wrap linker mechanism to intercept every call
to xTaskCreatePinnedToCore. Any task created with tskNO_AFFINITY is
redirected to core 0. Tasks that are already explicitly pinned (Wi-Fi
driver, LwIP, httpd, esp_timer, ipc0/ipc1) are passed through unchanged.
We intentionally do not filter by task name. Pinning all unpinned tasks
makes the approach robust against internal ESP-IDF task name changes and
catches any future tasks that may be added with tskNO_AFFINITY.
Verified task layout after the change:
loopTask pri=1 core=1 (Arduino loop / LoRa — unchanged)
mqtt_task pri=5 core=0 (was tskNO_AFFINITY, now pinned)
httpd pri=2 core=0 (core_id set explicitly in WebPanelServer)
tiT pri=18 core=0 (LwIP, already pinned by ESP-IDF)
wifi pri=23 core=0 (Wi-Fi driver, already pinned)
esp_timer pri=22 core=0 (already pinned)
ipc0/ipc1 pri=24 core=0/1 (IPC, already pinned per-core)
The -Wl,--wrap flag and arch/esp32/task_pinning.c are added only to
[esp32_base] (IDF v4). The ESP32-C6 pioarduino target (IDF v5) is
unaffected and can use vTaskCoreAffinitySet() if needed in the future.
Patches Bluefruit library to fix semaphore leak bug that causes device lockup
when BLE central disconnects unexpectedly (e.g., going out of range, supervision timeout).
Co-authored-by: Liam Cottle <liamcottle@users.noreply.github.com>
Co-authored-by: oltaco <oltaco@users.noreply.github.com>
Valentin V. Bartenev