STM32H563 I3C IBI Payloads: Qualify Interrupt Data Separately from Private Transfers
A successful private read from an I3C sensor does not qualify its in-band interrupt payload. On the STM32H563 implementation, IBI data follows a dedicated four-byte path. When the target supplies IBI data, that total includes the mandatory data byte, or MDB. A target requiring an MDB plus four additional bytes exceeds that path.
The reference is RM0481 Rev 5, chapter 55, specifically the main features and I3C_IBIDR, I3C_RMR and I3C_MAXRLR definitions. Chapter 54 covers a different implementation and must not substitute for H563. This is a compatibility worksheet; no sensor traffic or firmware was executed.
Budget the interrupt bytes independently
A private transfer reads or writes application data through its normal message path. An IBI is a target-initiated request with separate acknowledgement, payload capability and event reporting. A test that reads sixteen bytes from a sensor register establishes nothing about whether that sensor’s six-byte IBI format fits.
For H563, the feature list specifies an IBI payload of up to four bytes. I3C_IBIDR has four byte fields. The earliest bus byte occupies IBIDB0, the least-significant byte, and is the MDB when a data-bearing IBI is present. Later bytes occupy IBIDB1 through IBIDB3 in arrival order.
For a hypothetical target, record its required total and whether a supported shorter format exists:
| Target’s documented IBI format | Total data bytes | Initial size decision |
|---|---|---|
| MDB only | 1 | Fits the payload capacity |
| MDB plus two status bytes | 3 | Fits the payload capacity |
| MDB plus three status bytes | 4 | Fits exactly |
| MDB plus four status bytes | 5 | Does not fit this data path |
“Fits” only resolves the byte budget. Event enablement, acknowledgement, target support and correct decoding remain requirements. There is no justified fix in simply throwing away the fifth byte and declaring the event valid.
Bind payload capability to the correct target
In controller operation, I3C_DEVRx.IBIACK controls acknowledgement for the configured target. IBIDEN reflects the target’s IBI-data capability, represented by its received BCR[2]. If the target has no IBI data, the payload register is not the source of a new valid payload merely because it contains an old value.
For a data-bearing acknowledged IBI, hardware writes received bytes into I3C_IBIDR. When the final payload byte arrives with the target’s terminating T-bit, IBIF is set. Software then has two essential items in I3C_RMR: RADD identifies the target’s received dynamic address, and IBIRDCNT reports the number of bytes actually received.
Preserve that source-and-count context with the bytes before application dispatch. A handler that assumes every event belongs to the last privately read sensor can decode a valid interrupt using the wrong device format. Dynamic address ownership must come from the current initialized bus, not a remembered address after re-enumeration.
Decode only the received bytes
Use an original three-byte fixture: MDB 0x12, followed by 0x34 and 0x56. With IBIRDCNT = 3, the valid register portion is 0x00563412 under mask 0x00FFFFFF. This expression describes byte placement; it does not claim the unreceived high byte was cleared by hardware.
A decoder should validate that the received count matches an allowed format for the identified target, then interpret only those valid bytes. For this fixture, treating all four register bytes as fresh data creates a fabricated fourth field. Conversely, rejecting every count below four would incorrectly reject the documented one-, two- and three-byte possibilities.
Keep the controller receive count distinct from I3C_MAXRLR.IBIP. The latter describes the maximum IBI payload when this peripheral acts as a target; it is not a controller setting that expands the physical four-byte receive register. Its encodings explicitly include the first MDB in the two-, three- and four-byte totals.
Resolve an oversized format before integration
If the selected sensor documents a pending-read notification scheme, a short supported IBI can notify the controller to obtain the larger data through a subsequent private read. Qualify that sensor’s exact notification and read protocol, including when its data remains valid. H563’s advertised pending-read support does not invent such a protocol for an arbitrary sensor.
Otherwise, choose a documented compatible sensor mode or controller. Record the unsupported format as a compatibility failure rather than relying on an accidental partial payload.
A proposed acceptance fixture should exercise one short and one maximum-size supported event, unexpected source identity, and a count inconsistent with the chosen format. Preserve bus bytes, logged address, count and application decode together. Private-transfer success remains a separate test. Completion means the sensor’s actual IBI contract fits the H563 path and every delivered event retains its correct source and valid length.
