159ef8105b
lsm6ds3trc_register() attached the INT1 handler without ever putting the sensor into a known state, which made every reboot a coin toss. The LSM6DS3TR-C has its own supply and its own reset. An MCU reset -- watchdog, RTS pin, esptool, a plain "reboot" -- does not reset it, so it comes back still holding whatever the previous session configured: for this driver, INT1_CTRL.INT1_FTH still set and a FIFO still over its watermark, i.e. INT1 already asserted at registration time. With the (correct) ONHIGH level trigger, arming an already-active line storms immediately. The board then wedges during bring-up with no console output and no crash dump -- it looked like a boot that stopped right after Wi-Fi init and never reached NSH. That symptom cost a long detour: it was blamed in turn on a stuck I2C bus, on corrupted NVS/Wi-Fi calibration, and finally on a failing USB-serial adapter, because the one thing that reliably cleared it was unplugging the board -- which is simply the only way to power-cycle the *sensor*. SW_RESET (CTRL3_C bit 0) clears INT1_CTRL and FIFO_CTRL back to 0, which deasserts INT1. It self-clears in ~50 us; poll for it rather than assume, and retry the write a few times, since the bus has been seen to return -EIO on the very first transaction after a cold boot. Carry on if the reset never takes. An unreset sensor risks the storm this exists to prevent, but refusing to register leaves the application with no /dev/uorb/sensor_accel0 at all, which is fatal to it -- a single -EIO here took the whole collar down once. Losing the sensor to guard against a maybe-storm is the wrong trade. Assisted-by: Claude:claude-opus-5 Signed-off-by: Felipe Moura <moura.fmo@gmail.com> |
||
|---|---|---|
| .github | ||
| arch | ||
| audio | ||
| binfmt | ||
| boards | ||
| cmake | ||
| crypto | ||
| Documentation | ||
| drivers | ||
| dummy | ||
| fs | ||
| graphics | ||
| include | ||
| libs | ||
| mm | ||
| net | ||
| openamp | ||
| pass1 | ||
| sched | ||
| syscall | ||
| tools | ||
| video | ||
| wireless | ||
| .asf.yaml | ||
| .codespell-ignore-lines | ||
| .codespellrc | ||
| .editorconfig | ||
| .gitignore | ||
| .gitmessage | ||
| .pre-commit-config.yaml | ||
| .yamllint | ||
| AUTHORS | ||
| CMakeLists.txt | ||
| CONTRIBUTING.md | ||
| INVIOLABLES.md | ||
| Kconfig | ||
| LICENSE | ||
| Makefile | ||
| NOTICE | ||
| README.md | ||
| ReleaseNotes | ||
Apache NuttX is a real-time operating system (RTOS) with an emphasis on standards compliance and small footprint. Scalable from 8-bit to 64-bit microcontroller environments, the primary governing standards in NuttX are POSIX and ANSI standards. Additional standard APIs from Unix and other common RTOSs (such as VxWorks) are adopted for functionality not available under these standards, or for functionality that is not appropriate for deeply-embedded environments (such as fork()).
For brevity, many parts of the documentation will refer to Apache NuttX as simply NuttX.
Getting Started
First time on NuttX? Read the Getting Started guide! If you don't have a board available, NuttX has its own simulator that you can run on terminal.
Documentation
You can find the current NuttX documentation on the Documentation Page.
Alternatively, you can build the documentation yourself by following the Documentation Build Instructions.
The old NuttX documentation is still available in the Apache wiki.
Supported Boards
NuttX supports a wide variety of platforms. See the full list on the Supported Platforms page.
Contributing
If you wish to contribute to the NuttX project, read the Contributing guidelines for information on Git usage, coding standard, workflow and the NuttX principles.
License
The code in this repository is under either the Apache 2 license, or a license compatible with the Apache 2 license. See the License Page for more information.