marwan-geotab opened a new pull request, #20233:
URL: https://github.com/apache/nuttx/pull/20233
## Summary
STM32H56xx's pin-mux table (`stm32h56xxx_pinmap.h`) is missing several
I2C2/I2C4 AF4 remap options that ST's datasheet defines as valid
alternate-function mappings. This adds the 8 missing `#define`s
(GPIO_I2C2_SDA_5, GPIO_I2C2_SMBA_2/3, GPIO_I2C4_SDA_5/6,
GPIO_I2C4_SCL_5/6, GPIO_I2C4_SMBA_4) — purely additive, no existing
symbol is changed.
This is a reduced extraction from a larger internal downstream patch;
the other part of that patch (renaming RCC_CCIPR4_I2C*SEL_PCLK*
defines in stm32_i2c.c, and zero-initializing some locals) is already
present in current upstream stm32_i2c.c independently, so it's
omitted here as a no-op.
Confirmed STM32H7's pinmap table does not have this gap — it's a
separate, already-complete table, so this is H5-specific.
## Impact
- Purely additive header change — no existing define, Kconfig option,
or board is affected.
- Enables boards that need I2C2 on PF0(SDA)/PB13 or PF2(SMBA), or I2C4
on PG6/PH12(SDA), PG7/PH11(SCL), PH10(SMBA) to compile against
upstream without carrying a local patch.
- No documentation, security, or compatibility impact.
## Testing
**Host:** Ubuntu 22.04.5 LTS, arm-none-eabi-gcc 10.3.1 (2021.07)
**1. Build regression check (in-tree board, `nucleo-h563zi`), against
current `apache/nuttx:master`:**
./tools/configure.sh nucleo-h563zi:nsh
make -j$(nproc)
Clean build, `LD: nuttx` / `CP: nuttx.bin` produced, no errors.
**2. Real hardware validation, against current `apache/nuttx:master`**
(custom STM32H563ZI-based board, minimal out-of-tree board port —
console + I2C2 only, no proprietary drivers, built with this patch's
single commit on top of an otherwise-unmodified `apache/nuttx`
checkout):
I2C2 initialized on `GPIO_I2C2_SDA_5`/`GPIO_I2C2_SCL_2` (PF0/PF1) and
registered via the standard `i2ctool` bringup pattern. From nsh:
nsh> i2c get -a 0x2c -b 2
READ Bus: 2 Addr: 2c Subaddr: 00 Value: 00
This is a genuine ACK from a real LED-driver IC on the bus, over the
new `GPIO_I2C2_SDA_5` remap.
Two negative controls to rule out a stuck/false-ACK bus:
- Same pins, wrong address (`0x55`, nothing lives there):
`Transfer failed: 1` (NACK), confirming the bus discriminates
between an address with a device and one without.
- Same address, wrong pin (temporarily remapped SDA to
`GPIO_I2C2_SDA_2`/PB12, not wired to the device): `Transfer failed:
1` (NACK). Reverting to `GPIO_I2C2_SDA_5` restored the ACK. This
isolates the result to the specific new pin remap, not "I2C2 happens
to work regardless of configured pin."
As a further check, drove the same I2C-addressable LED driver's
registers directly via `i2c set` (no proprietary driver, plain
register writes) to set an RGB color, and visually confirmed the LED
lit the commanded color — a second, independent line of evidence on
top of the ACK reads.
--
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]
