FelipeMdeO opened a new pull request, #20231:
URL: https://github.com/apache/nuttx/pull/20231
## Summary
Three related robustness fixes for the LSM6DS3TR-C driver
(`drivers/sensors/lsm6ds3trc_uorb.c`), found during extended bench
testing with the FIFO watermark raised well above the Kconfig default:
1. **Reset the sensor before arming its interrupt.** The LSM6DS3TR-C has
its own supply and its own reset — an MCU reset (watchdog, RTS pin,
esptool, `reboot`) does not reset it, so it comes back still holding
whatever the previous session configured: `INT1_CTRL.INT1_FTH` still
set, a FIFO still over its watermark, i.e. INT1 already asserted at
registration time. Arming a level-triggered line on top of that storms
immediately and wedges the board during bring-up with no console
output and no crash dump — a symptom that cost a long detour, blamed in
turn on a stuck I2C bus, corrupted NVS/Wi-Fi calibration, and a failing
USB-serial adapter, because the one thing that reliably cleared it was
unplugging the board (the only way to power-cycle the *sensor*). Fix:
issue `SW_RESET` (`CTRL3_C` bit 0) before attaching the interrupt; poll
for its ~50 us self-clear rather than assume, retry the write a few
times (the bus has been seen to return `-EIO` on the first transaction
after a cold boot), and carry on registration even if the reset never
takes — refusing to register leaves the application with no
`/dev/uorb/sensor_accel0` at all, which is worse.
2. **Move the FIFO drain buffer off the stack.** `FIFO_MAX_WORDS` scales
with `CONFIG_SENSORS_LSM6DS3TRC_FIFO_WATERMARK` — 192 bytes at the
Kconfig default of 8, invisible; 6000 bytes (73% of an 8192-byte HPWORK
stack) at a watermark of 250. Now allocated once at registration, so
the drain path stays allocation-free and registration fails cleanly if
the allocation cannot be made.
3. **Recover from a failed FIFO drain instead of wedging.** A failed burst
read of `FIFO_DATA_OUT` left the FIFO above watermark with no
recovery; the level-triggered INT1 stayed asserted, the worker was
re-entered the instant the IRQ was re-enabled, failed again, and that
hot loop starved every other task — observed killing a board within
seconds of the first failure. Fix: if the read fails, empty the FIFO
through Bypass mode and restore the previous mode bits (rather than
recomputing them, to preserve the FIFO-only ODR `fifo_configure()`
set) — losing one batch of samples is a far better outcome than losing
the board. The read itself is not retried: the only reproduced cause
of this failure was light sleep cutting the I2C transfer in half,
fixed at the root in #20227 ("esp32s3/esp32s3_i2c.c: hold off light
sleep for the duration of an I2C transfer"), so this is graceful
degradation for whatever residual cause, not a workaround.
## Impact
* Is new feature added? No — robustness fixes for an existing driver.
* Is existing feature changed? No behavior change on the success path;
changes only what happens on paths that previously wedged the board.
* Impact on hardware? `drivers/sensors/lsm6ds3trc_uorb.c` — any board
using this driver, more exposed at higher FIFO watermarks.
## Testing
I confirm that changes are verified on local setup and works as intended:
* Build Host: Ubuntu 24.04, x86_64, `xtensa-esp-elf-gcc`.
* Target: Xtensa, Seeed XIAO ESP32-S3 (esp32s3-xiao),
`CONFIG_SENSORS_LSM6DS3TRC_FIFO_WATERMARK=250`.
Item 1: before the fix, a cold boot with a FIFO already over watermark
wedged the board every time (2/2 reflashes tested); after, registration
completes cleanly regardless of the sensor's pre-existing state. Item 2:
watermark 250 previously walked directly into the stack overflow;
allocation-based drain has now run for a 12 h 25 continuous production
run with zero corruption. Item 3: validated across the same 12 h 25 run —
zero FIFO failures, zero faults, zero asserts over thousands of drains.
Depends on #20230 ("espressif/esp_irq.c: fix up_disable_irq()/up_enable_irq()
for GPIO IRQs") — that commit is included here too since it has not merged
yet, so the diff currently shows all four commits. Once #20230 merges,
this branch will be rebased onto master and only its own three commits
will remain.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
