Aurora-QIU0 opened a new pull request, #20164:
URL: https://github.com/apache/nuttx/pull/20164
## Summary
esp_i2c.c composes the pin attribute masks passed to esp_configgpio() with
the
logical OR operator instead of the bitwise OR operator:
#define SCL_PIN_ATTR (FUNCTION_2 || INPUT_PULLUP || OUTPUT_OPEN_DRAIN)
#define SDA_PIN_ATTR (FUNCTION_2 || INPUT_PULLUP || OUTPUT_OPEN_DRAIN)
Every operand is a non-zero bit field, so the expression collapses to 1
instead
of the intended mask. With the encodings in esp_gpio.h the mask must be 171
(0xab):
FUNCTION_2 (2 << FUNCTION_SHIFT) = 128
INPUT_PULLUP (INPUT | PULLUP) = 9
OUTPUT_OPEN_DRAIN (OUTPUT | OPEN_DRAIN) = 34
Passing 1 selects input mode only: output and open-drain stay disabled, the
pull-up is not enabled and the function field does not match, so the pin
falls
back to plain GPIO function. The I2C signal never reaches the pads while the
transfer state machine still reports completion.
Every other pin attribute mask in this directory (esp_i2c_slave.c,
esp_i2c_bitbang.c, esp_spi.c, esp_twai.c) already uses the bitwise operator
for
the same encodings, so esp_i2c.c is the only outlier.
## Impact
- New feature? NO
- Impact on user? NO (only corrects pin mux for I2C)
- Impact on build? NO
- Impact on hardware? YES (risc-v/espressif I2C)
- Impact on documentation? NO
- Impact on security? NO
- Impact on compatibility? NO
## Testing
This fix was validated on real hardware during an ESP32-P4 board bring-up.
The logical-OR mask left the I2C pins floating (bus never ACKed); after
switching to bitwise OR the bus enumerated correctly. (Hardware logs
available
on request; the board was an ESP32-P4 Function EV Board running NuttX.)
--
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]
