This is an automated email from the ASF dual-hosted git repository.
michallenc pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/nuttx.git
The following commit(s) were added to refs/heads/master by this push:
new 4818198a0dd drivers/lsm6ds3trc_uorb.c: keep the reset comment
board/arch-agnostic
4818198a0dd is described below
commit 4818198a0dd0276f55c05684d08877ff72a41613
Author: Felipe Moura <[email protected]>
AuthorDate: Tue Sep 22 11:39:21 2026 -0300
drivers/lsm6ds3trc_uorb.c: keep the reset comment board/arch-agnostic
#20231 added a comment ahead of the sensor's power-on SW_RESET that
named esp32s3-specific things in otherwise generic driver code:
esptool/RTS-pin reset vocabulary, a literal path to
boards/xtensa/esp32s3/common/src/esp32s3_board_lsm6ds3trc.c, and the
espressif-arch esp_gpioirqenable() function.
None of that is specific to this driver's actual logic, which is
reached by any board wiring this sensor's INT1 through its own
config->attach() callback, whatever the arch. Reworded to describe
the reset/level-trigger requirement in those generic terms instead,
and dropped an ESP32S3-collar bring-up anecdote that does not belong
in driver documentation.
Signed-off-by: Felipe Moura <[email protected]>
Assisted-by: Claude:claude-sonnet-5
---
drivers/sensors/lsm6ds3trc_uorb.c | 24 ++++++++++--------------
1 file changed, 10 insertions(+), 14 deletions(-)
diff --git a/drivers/sensors/lsm6ds3trc_uorb.c
b/drivers/sensors/lsm6ds3trc_uorb.c
index f61c658a6b1..a10c3d2e2b8 100644
--- a/drivers/sensors/lsm6ds3trc_uorb.c
+++ b/drivers/sensors/lsm6ds3trc_uorb.c
@@ -1675,21 +1675,17 @@ int lsm6ds3trc_register(FAR struct i2c_master_s *i2c,
uint8_t addr,
/* Put the sensor into its power-on register state before anything else
* touches it, and in particular before the interrupt is attached.
*
- * The LSM6DS3TR-C has its own supply and its own reset: an MCU reset
- * (watchdog, RTS pin, esptool, `reboot`) does not reset the sensor, so
- * it comes up still holding whatever the previous session configured.
- * For this driver that means INT1_CTRL.INT1_FTH still set and a FIFO
- * still over its watermark -- i.e. INT1 asserted high, immediately, at
- * registration time.
+ * The LSM6DS3TR-C has its own supply and its own reset: a plain MCU
+ * reset does not reset the sensor, so it comes up still holding
+ * whatever the previous session configured. For this driver that
+ * means INT1_CTRL.INT1_FTH still set and a FIFO still over its
+ * watermark -- i.e. INT1 asserted, immediately, at registration time.
*
- * INT1 is level-triggered (ONHIGH; see the comment in
- * boards/xtensa/esp32s3/common/src/esp32s3_board_lsm6ds3trc.c for why
- * edge triggering is wrong here). A level-triggered line that is
- * already active when esp_gpioirqenable() runs re-fires forever, and
- * the board then wedges during bring-up with no console output and no
- * crash dump -- observed as a boot that stops right after Wi-Fi init
- * and never reaches NSH, recoverable only by physically removing power
- * from the sensor.
+ * The board is expected to configure INT1 as level-triggered (a FIFO
+ * watermark is a level condition, not a pulse). Arming an interrupt
+ * on a line that is already active when config->attach() enables it
+ * can re-fire continuously and wedge the caller with no diagnostic
+ * output, depending on the arch's own interrupt-controller behavior.
*
* SW_RESET (CTRL3_C bit 0) clears INT1_CTRL and FIFO_CTRL back to 0,
* which deasserts INT1. It self-clears in ~50us; poll rather than
