jerpelea opened a new pull request, #20322: URL: https://github.com/apache/nuttx/pull/20322
## Summary Light sleep gates the APB clock the I2C peripheral runs on. A transfer in flight stops mid-message and never raises its completion interrupt, so the caller blocks in i2c_sem_waitdone() until ESP32S3_I2CTIMEOTICKS expires and gets -ETIMEDOUT for a bus that was working perfectly. The caller is what causes it. Blocking in i2c_sem_waitdone() is exactly what makes the idle task runnable, and the idle task is what decides to sleep -- so the longer the transfer, the likelier it is to be cut in half by its own wait. Nothing about this is driver-specific. Seen on an esp32s3-xiao reading an LSM6DS3TR-C FIFO: 6000 bytes in one transaction, some 135 ms of bus time at 400 kHz, failing with -110 over and over. A WHO_AM_I probe and the FIFO status read, both short, never failed once in the same runs -- only the long burst did. The consequences went well past one failed read. With the FIFO left undrained the sensor's level-triggered INT1 stayed asserted, the worker was re-entered the moment the IRQ was re-enabled, and that hot loop starved every other task until the board wedged with no console output and no crash dump. pm_stay(PM_IDLE_DOMAIN, PM_IDLE) is the lightest lock that suffices: greedy_governor_checkstate() walks up from PM_NORMAL and stops at the first state holding a wakelock, so a stay at PM_IDLE keeps the domain out of PM_STANDBY and PM_SLEEP while still allowing the plain WFI idle. There is no early return between the stay and the relax. Validated over 3 h 45 of continuous acquisition across two sessions: wakes and drains stayed 1:1 (302/302, then 375/375), zero I2C failures of any kind, and light sleep itself unaffected -- 11.8% of wall time asleep in both, median sleep 2.08 s. ## Impact RELEASE ## Testing CI -- 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]
