2406827_en-US

はい

LPC55S69: I2C registers all correct, but SDA/SCL never physically move

LPC55S69: I2C4 (Flexcomm 4) master never physically drives SDA/SCL despite fully correct register configuration - I2C_MasterStart() hangs permanently in I2C_MasterCheckStartResponse()

Summary

On an LPC55S69-EVK, I2C_MasterTransferBlocking() hangs permanently (no timeout, confirmed via SDK source inspection) on the very first transaction attempted after I2C_MasterInit(). Every peripheral configuration register I can inspect - CFG, PSELID, CLKDIV, MSTTIME, IOCON pin function, and the Secure AHB Controller's peripheral access rules - reads back as correctly configured. However, a direct multimeter measurement of the physical SDA/SCL lines, taken while execution is frozen mid-hang inside the driver, shows both lines sitting at a clean, unchanged idle ~3.3V - meaning the I2C master's internal state machine never actually asserts a START condition onto the physical bus at all, despite software believing it did.

Environment

Board: LPCXpresso55S69-EVK, LPC55S69JBD100
IDE: MCUXpresso IDE v25.6 [Build 136]
I2C peripheral: I2C4 (Flexcomm 4), pins P1_20 (SCL) / P1_21 (SDA)
This is Core 1 (non-secure, no TrustZone - confirmed this chip's Core 1 has no TrustZone capability at all per AN12278) of a dual-core project. Core 1 is confirmed booting and executing correctly (proven via a working LED heartbeat and independent shared-memory diagnostics) - this report is specifically about the I2C peripheral, not the multicore boot sequence.
Sensor: Adafruit BME688 (STEMMA QT, onboard pull-ups), address 0x77, connected via genuine Adafruit STEMMA QT-to-header cable

The core evidence

1. The hang location, confirmed via SDK source inspection

Reading fsl_i2c.c directly: I2C_MasterTransferBlocking() calls I2C_MasterStart() then I2C_MasterCheckStartResponse(). The latter calls I2C_PendingStatusWait(), which polls kI2C_MasterPendingFlag in a loop with no timeout at all when I2C_RETRY_TIMES is 0/undefined (confirmed this is the active code path in this project - the #else branch with an unconditional while(...) and no exit condition). Execution never returns from this call, confirmed by a shared-memory diagnostic checkpoint written immediately before the call, which is reached, and one written immediately after, which is never reached, even after 5+ seconds of continuous execution.

2. Register state at the moment of the hang (read live via debugger, not assumed)

Register Address Value Meaning

I2C4->STAT	0x5008A000	0x00000000	Idle. MSTPENDING=0, MSTSTATE=0, no error flags
I2C4->CFG	0x5008A800	0x00000001	MSTEN=1 - master mode enabled
FLEXCOMM4->PSELID	0x5008AFF8	0x1020F3	PERSEL=3 (I2C personality genuinely selected), I2CPRESENT=1
I2C4->CLKDIV	0x5008A814	74	Non-zero, plausible divider
I2C4->MSTTIME	0x5008A824	102	Non-zero, plausible SCL timing
IOCON->PIO[1][20] (P1_20/SCL)	0x500010D0	0x323	FUNC=3 (Flexcomm alt-function), pull-up + open-drain enabled
IOCON->PIO[1][21] (P1_21/SDA)	0x500010D4	0x323	Same - correctly configured
AHB_SECURE_CTRL FLEXCOMM4_RULE	0x500AC124	0	0b00 = "Non-secure and Non-privilege user access allowed" (most permissive)
AHB_SECURE_CTRL IOCON_RULE	0x500AC130	0	Same - fully open, non-secure access unrestricted

Every one of these is exactly what a correctly-configured, unrestricted, ready-to-transact I2C master should show.

3. Physical measurement (the decisive evidence)

With execution frozen mid-hang (confirmed via the checkpoint diagnostic, STAT still reading 0x00000000 at this exact moment):

SDA to GND: 3.299 V
SCL to GND: 3.299 V

Both lines are indistinguishable from a fully idle, untouched bus. The physical pins never moved at all, despite I2C_MasterStart() having already executed (it's called before I2C_MasterCheckStartResponse(), where we're actually hung) and despite every register above showing a fully configured, unrestricted master.

What has been ruled out

Sensor/cable/breadboard fault - wiring continuity confirmed with a multimeter across multiple different physical wire positions (5+ attempts); genuine Adafruit STEMMA QT cable; sensor address pad confirmed consistent with the documented 0x77 default; identical result reproduces regardless of which physical header pins are used
Clock source/frequency - explicitly re-asserted CLOCK_SetupFROClocking(12000000U) immediately before attaching Flexcomm4's clock; no change
Baud rate/timing miscalculation - reduced from 100 kHz to 10 kHz (10x); identical hang; CLKDIV/MSTTIME both confirmed non-zero and plausible
Pin mux - confirmed via IOCON_FUNC3 write and independently re-verified via direct register read at the exact moment of the hang
I2C personality selection - confirmed via PSELID
Sensor driver library - bypassed bme68x.c entirely; a raw, minimal zero-length address probe built directly with the SDK's i2c_master_transfer_t struct produces the identical hang
MasterEnable off/on toggle workaround (from a similar-sounding NXP community report for a different part) - no effect
TrustZone/Secure AHB Controller peripheral access restriction - confirmed both IOCON and FLEXCOMM4 are set to the most permissive non-secure access rule

Question

Given every software-visible register indicates a correctly configured, unrestricted I2C master, but the physical SDA/SCL pins provably never move (confirmed by direct voltage measurement while frozen inside the driver call), what remaining hardware-level step is required to get the I2C4 peripheral to actually drive its pads on this part?

Specifically:

Is there a known LPC55S69 errata affecting Flexcomm I2C pad drive that isn't captured by the CFG/PSELID/IOCON registers I've checked?
Is there an additional power-domain, pad-supply, or analog block that needs to be explicitly enabled for Flexcomm I2C physical output (something outside the digital peripheral configuration registers) that I may have missed?
Given this is Core 1 (bare-metal, no RTOS, no TrustZone) in a dual-core multicore project where Core 0 runs FreeRTOS - is there any known interaction between Core 0's own boot-time configuration and Core 1's ability to drive Flexcomm4's physical pads, beyond what a register-level snapshot would reveal (e.g., something in SYSCON clock-gating for the pad IO cell itself, distinct from CLOCK_AttachClk's peripheral function clock)?

Happy to provide the full project, a logic analyzer capture, or any additional register dump on request.

LPC55xx

Re: LPC55S69: I2C registers all correct, but SDA/SCL never physically move

Resolved - root cause was an incorrect IOCON alternate function number

Posting the resolution in case anyone finds this thread later with a similar symptom.

The actual root cause

IOCON_PIO_FUNC3 does not route P1_20/P1_21 to FC4 I2C on this board. The correct alternate function is FUNC5, with open-drain disabled at the IOCON level (the I2C peripheral's own CFG register handles open-drain behavior internally - enabling it again at the IOCON pad level was also wrong).

I had derived FUNC3 by reading the pin_signal ordering in a comment (PIO1_20/FC7_RTS_SCL_SSEL1/CT_INP14/FC4_TXD_SCL_MISO_WS/PLU_OUT2) and assuming 0-indexed position = function number. That assumption was incorrect for this pin.

Why this produced such a confusing symptom

With the wrong alternate function selected, every I2C-internal register still read back as perfectly configured:

I2C4->CFG.MSTEN = 1 (master enabled)
FLEXCOMM4->PSELID showed I2C personality genuinely selected
CLKDIV/MSTTIME were valid, non-zero
Even IOCON->PIO[1][20/21] showed a function selected (just the wrong one) - nothing about this register's value alone signals "wrong function," only "some function is selected"

None of that depends on the physical pin actually being connected to the I2C block - PSELID and CFG are entirely internal to the Flexcomm/I2C logic, independent of which alternate function the IOCON mux happens to route to. So the peripheral was internally fully configured and "ready," while the physical SDA/SCL pins were never actually wired to it at all. This produced a permanent hang in I2C_MasterTransferBlocking() (confirmed via SDK source: no timeout when I2C_RETRY_TIMES is 0) with zero error flags ever raised, and - the piece that finally proved it - a multimeter measurement showing the physical bus completely unchanged at idle voltage even while frozen mid-transaction, since the pins genuinely were never driven.

How it was found

Created a fresh, separate single-core test project for the same board and used the MCUXpresso wizard's own auto-generated BOARD_InitACCELPins() function (this board has an onboard accelerometer wired to the same I2C4 bus, so the wizard ships a working, verified pin mux for these exact pins). Reading that function's actual generated source showed IOCON_PIO_FUNC5 with open-drain disabled - directly contradicting my own hand-derived FUNC3/open-drain-enabled configuration. Switching to match NXP's own verified values immediately resolved the permanent hang; a subsequent, unrelated address-NAK (0x77 not acknowledging) turned out to just be a loose header-pin contact, resolved by moving the connection to different header pins.

Lesson for anyone else hitting an identical symptom

If a Flexcomm peripheral's own registers (PSELID, CFG, CLKDIV, etc.) all read back as correctly configured but the physical bus never shows any activity (confirmed via multimeter/scope) - don't trust a hand-derived alternate function number from reading the pin_signal comment ordering. Cross-check against any wizard-auto-generated pin mux function this SDK ships for the same physical pins on the same board (peripherals the eval board itself uses - accelerometers, codecs, etc. - are a good source of a genuinely verified reference), or regenerate the pin mux via the MCUXpresso Pins tool directly rather than hand-writing IOCON_PinMuxSet() calls from an assumed function index.

Thanks again to everyone who engaged with the earlier posts in this thread and the original multicore boot thread - the register-level verification work across both investigations is what eventually made this contradiction (everything configured correctly, yet nothing on the bus) visible enough to chase down.