Repository navigation
Drain the STM32 HAL Ethernet RX ring on every poll and wake the FreeRTOS poll task - #191
Conversation
824f038 to
479cd20
Compare
479cd20 to
e44f725
Compare
There was a problem hiding this comment.
🔵 Needs a closer look
RX buffer ownership and cache coherency depend on family-specific HAL contracts unavailable in this checkout, requiring human validation of descriptor rearming and cache-enabled DMA behavior beyond the tested H7S3.
No open issues 🎉
What changed in this PR
Addresses #190’s receive latency and frame loss in the STM32 HAL Ethernet driver, particularly when used with the FreeRTOS port.
Changes:
- Reads RX data on every poll, adds separate receive buffers, performs cache maintenance, and optionally wakes the FreeRTOS poll task from the RX interrupt.
- Documents FreeRTOS integration, interrupt-priority requirements, and updated driver behavior.
- Raises emulated TLS client timeouts and makes the optional kernel-module package installation conditional.
| File | Description |
|---|---|
tools/scripts/test-interop-wolfguard.sh |
Installs linux-modules-extra only when available. |
src/port/stm32_hal/stm32_hal_eth.h |
Updates polling, buffer, cache, and interrupt documentation. |
src/port/stm32_hal/stm32_hal_eth.c |
Implements RX polling, buffer rotation, cache maintenance, and FreeRTOS wakeups. |
src/port/freeRTOS/README.md |
Documents the STM32 HAL notifier integration and interrupt-masking exception. |
IDE/STM32Cube/README.md |
Adds FreeRTOS build and ETH interrupt-priority guidance. |
.github/workflows/stm32h563-m33mu.yml |
Increases HTTPS and TLS echo client timeouts to 60 seconds. |
Review effort: Balanced
wolfSSL-Fenrir-bot
left a comment
There was a problem hiding this comment.
Fenrir Automated Review — PR #191
Scan targets checked: wolfip-src, wolfip-bugs
Not reviewed (no scan target covers them): .github/workflows/stm32h563-m33mu.yml, IDE/STM32Cube/README.md, src/port/freeRTOS/README.md, tools/scripts/test-interop-wolfguard.sh
Coverage: 2 of 2 in-scope changed file(s) opened by the reviewer
Findings: 1
1 finding(s) posted as inline comments (see file-level comments below)
This review was generated automatically by Fenrir. Reported findings require changes before merge.
Review tier: Max
e44f725 to
af7db52
Compare
Description
Fixes #190. Three problems in
src/port/stm32_hal/stm32_hal_eth.cthat together lost or delayed received frames, most visibly under the FreeRTOS port.1. Only one frame was read per RX interrupt
hal_eth_poll()cleared the interrupt flag and calledHAL_ETH_ReadData()once, which returns a single frame. The DMA raises one RX interrupt for a burst, so a frame queued behind another waited for the next interrupt or the every-100th-poll fallback. In a bare-metal loop that fallback comes around almost at once; under the FreeRTOS poll task each poll is a sleep, so it surfaced as TCP retransmission-sized stalls. Each poll now callsHAL_ETH_ReadData(), andwolfIP_poll()keeps calling until the ring is empty.2. All RX descriptors shared one buffer
HAL_ETH_RxAllocateCallback()handed every descriptor the same buffer, so a back-to-back frame could be written over the one waiting to be copied. The driver now keepsETH_RX_DESC_CNT + 1buffers handed out in ring order; the extra one coversHAL_ETH_ReadData()re-arming the descriptor before it returns the frame. The link callback keeps the HAL's frame-start pointer set so every consumed descriptor is detached and refilled in that order; a frame longer thanRxBuffLen, which spans several descriptors, is dropped.3. No cache maintenance on Cortex-M7
With the D-cache enabled and the buffers in cacheable RAM, the CPU could read stale RX data and the DMA could send stale TX data. RX buffers are now invalidated before the copy and TX frames cleaned before transmit when the D-cache is on.
Notes
WOLFIP_USE_FREERTOSdefined, the RX interrupt callswolfip_freertos_notify_from_isr(). It does not mask itself asdocs/porting_guide.mdsuggests: the HAL IRQ handler clears the RX status only while the RX interrupt is enabled, so masking it from the RX callback can leave the interrupt asserted with nothing to clear it.CI
Two jobs that also fail on master, each fixed in its own commit:
timeout 10around the TLS echo client and the HTTPS test'scurl --max-time 20is close behind. The handshake time does not depend on the wolfSSL, wolfSSH or wolfMQTT versions the job clones; the same firmware built against the versions from the last green run takes as long in the same container. Both client limits are raised to 60 seconds.linux-modules-extrapackage, and the tunnel modules it needs ship inlinux-modules.test-interop-wolfguard.shinstallslinux-modules-extraonly when apt has one.Testing
Validated on a NUCLEO-H7S3L8 (STM32H7S3, LAN8742, D-cache on,
ETH_RX_DESC_CNT4) under the FreeRTOS port, with a new TCP connection per HTTP request, with and withoutWOLFIP_USE_FREERTOS, and under sustained ping load alongside a CPU-bound lower-priority task. Not tested on other STM32 families.