How to implement nonblocking API GetStatus

[Bruce_Teng]

 Hi everyone, From our experiments, we observed that MSTATUS remains stuck in the SLVREQ state, causing the MCU to treat the I3C bus as busy.

We found that in certain scenarios, calling the blocking GetStatus API triggers this issue. We believe the root cause is mixing blocking and non‑blocking APIs, which leads to incorrect IBI handling. We’d like to implement a non‑blocking GetStatus to address this. Could you help with the implementation?

MCU: mcxn556 and mcxn236

[carlos_o]

Hi @Bruce_Teng 

Thanks for your post, and apologies for the delayed reply.

Could you please share more details about what you’re testing (test steps, expected vs. observed behavior, and any logs or traces)?

I’m assuming the MCU is configured as Master, since you’re checking MSTATUS rather than SSTATUS. If that’s not the case, please let me know.

From the reference manual, the interface behavior in this condition is described as follows:

You might try enabling auto‑emit IBI so the bus does not remain in that state.

A few clarifications to help us reproduce your setup:

Which GetStatus API are you referring to (full function name and module/driver)?

SDK version you are using (exact version string).

Role and configuration: Master vs. Slave, and any relevant register settings (e.g., FIFO thresholds, interrupt masks).

Hardware: MCU/board part number and any external components on the bus.

Timing: Bus frequency, IBI configuration, and whether clock stretching or retries are enabled.

Minimal code snippet that shows how you configure and call the API.

[Bruce_Teng]

Hi @carlos_o ,
The following codes are implementation of Blocking API GetStatus

 get_status(uint8_t address, uint16_t& status)
{
    constexpr uint8_t     BoradcastAddress = 0x7EU;
    constexpr uint8_t     CccGetStatus     = 0x90U;
    constexpr uint16_t    WordMask         = 0xFFFF;
    I3cBuffer             buffer{};
    i3c_master_transfer_t xfer{};
    xfer.slaveAddress   = BoradcastAddress;
    xfer.subaddress     = CccGetStatus;
    xfer.subaddressSize = 1U;
    xfer.direction      = kI3C_Write;
    xfer.busType        = kI3C_TypeI3CSdr;
    xfer.flags          = kI3C_TransferNoStopFlag;
    xfer.ibiResponse    = kI3C_IbiRespAckMandatory;
    auto result         = I3C_MasterTransferBlocking(_i3c_m_handle.base, &xfer);
    if (result != kStatus_Success) {
        I3C_MasterEmitRequest(_i3c_m_handle.base, kI3C_RequestForceExit);
        const logger::EventData data = {
            CccGetStatus,
            static_cast<uint8_t>(result >> 0 & 0xFF),
            static_cast<uint8_t>(result >> 8 & 0xFF),
            static_cast<uint8_t>(result >> 16 & 0xFF),
            static_cast<uint8_t>(result >> 24 & 0xFF),
        };
        logger::info(logger::Event::I3CCccError, data);
        auto driver_status = to_driver_status(static_cast<uint32_t>(result));
        if (driver_status != Status::Success) {
            const auto& task = *static_cast<nv::i3c::Task*>(_task);
            task.record_error(static_cast<uint8_t>(driver_status));
        }
        return false;
    }
    memset(&xfer, 0, sizeof(xfer));
    xfer.slaveAddress = address;
    xfer.data         = buffer.data();
    xfer.dataSize     = 2;
    xfer.direction    = kI3C_Read;
    xfer.busType      = kI3C_TypeI3CSdr;
    xfer.flags        = kI3C_TransferDefaultFlag;
    xfer.ibiResponse  = kI3C_IbiRespAckMandatory;
    result            = I3C_MasterTransferBlocking(_i3c_m_handle.base, &xfer);
    if (result != kStatus_Success) {
        I3C_MasterStop(_i3c_m_handle.base);
        const logger::EventData data = {
            CccGetStatus,
            static_cast<uint8_t>(result >> 0 & 0xFF),
            static_cast<uint8_t>(result >> 8 & 0xFF),
            static_cast<uint8_t>(result >> 16 & 0xFF),
            static_cast<uint8_t>(result >> 24 & 0xFF),
        };
        logger::info(logger::Event::I3CCccError, data);
        auto driver_status = to_driver_status(static_cast<uint32_t>(result));
        if (driver_status != Status::Success) {
            const auto& task = *static_cast<nv::i3c::Task*>(_task);
            task.record_error(static_cast<uint8_t>(driver_status));
        }
        return false;
    }
    status = (buffer[0] << 8 | buffer[1]) & WordMask;
    return true;
}

SDK version:  SDK_25_09_00_MCXN556S
Role and configuration:

Master Mode - The I3C controller is configured as a master device.

The I3C master configuration is set up as follows:

i3c_master_config_t _master_config;

// Configuration settings:

_master_config.baudRate_Hz.i2cBaud          = freq.i2c;          // I2C baud rate (typically 400 kHz)

_master_config.baudRate_Hz.i3cPushPullBaud  = freq.i3c_pp;      // I3C push-pull baud rate (typically 12.5 MHz)

_master_config.baudRate_Hz.i3cOpenDrainBaud  = freq.i2c_od;      // I3C open-drain baud rate (typically 2.5 MHz)

_master_config.enableOpenDrainStop          = false;

_master_config.disableTimeout               = true;             // Timeout disabled

_master_config.enableOpenDrainHigh          = is_gpu ? true : false;  // GPU-specific: 50:50 duty cycle

_master_config.hKeep                         = kI3C_MasterHighKeeperNone;

```

Transfer Mode:** SmartDMA and EDMA (Enhanced DMA) based transfers

DMA Configuration

- **TX DMA Channel:** Channel 0 (DMA0 for I3C0, DMA1 for I3C1)

- **RX DMA Channel:** Channel 1 (DMA0 for I3C0, DMA1 for I3C1)

- **DMA Mux:** Configured for I3C TX/RX requests

Hardware

MCU/Board Part Numb

MCXN556 (MCXN556SCDF variant)

The code supports two I3C ports:

- **I3C0:** Base address `I3C0`, uses `DMA0`

- **I3C1:** Base address `I3C1`, uses `DMA1`

The I3C bus is used to communicate with GPU devices

Bus Frequency

- **Master Clock:** 25 MHz (`Clock = 25000000UL`)

- **I3C Push-Pull Baud Rate:** 12.5 MHz (typical)

- **I3C Open-Drain Baud Rate:** 2.5 MHz (typical)

- **I2C Baud Rate:** 400 kHz (typical)

### Clock Stretching and Retries

- **Timeout:** Disabled (`disableTimeout = true`)

- **Retry Mechanism:** Implemented in software with 5 retry attempts for failed transfers

Nack occurred when MCU read/write data to the slave.
MCU send GetStatus command to GPU to recover it.

    for (uint8_t i = 0; i < recover_retry; i++) {
        bool success = get_status(address, value);
        if (success && value == 0) {
            return true;
        }
        task->delay(10ms);
    }​

[Bruce_Teng]

bool i3c_write(uint8_t address, uint8_t* data, size_t length) {
    i3c_master_transfer_t xfer = {};
    xfer.slaveAddress  = address;
    xfer.data         = data;
    xfer.dataSize     = length;
    xfer.direction    = kI3C_Write;
    xfer.busType      = kI3C_TypeI3CSdr;
    xfer.flags        = kI3C_TransferDefaultFlag;
    xfer.ibiResponse  = kI3C_IbiRespAckMandatory;
    
    status_t status = I3C_MasterTransferEDMA(I3C0, &i3c_handle, &xfer);
    return (status == kStatus_Success);
}
```

### Read Operation

```cpp
bool i3c_read(uint8_t address, uint8_t* data, size_t length) {
    i3c_master_transfer_t xfer = {};
    xfer.slaveAddress  = address;
    xfer.data          = data;
    xfer.dataSize      = length;
    xfer.direction     = kI3C_Read;
    xfer.busType       = kI3C_TypeI3CSdr;
    xfer.flags         = kI3C_TransferDefaultFlag;
    xfer.ibiResponse   = kI3C_IbiRespAckMandatory;
    
    status_t status = I3C_MasterTransferEDMA(I3C0, &i3c_handle, &xfer);
    return (status == kStatus_Success);
}

If we use this blocking API get_status to implement the recovery for the private read/write NACK, it seems that it causes the MCU to enter an error state(as I mentioned).
We reverted the recovery method and stress tested this version; it would never happen again.

[Bruce_Teng]

Hi,
I have another problem.
if f slave pulls SDA line low immediately after the STOP condition as picture.
It seems like MCXN556/236 I3C IP can't detect the SDA failing edge, so it will not toggle SCL line to generate a START. 
Does it match your expectation?
If yes, does it due to slave violate the Bus available condition? 

 

[Habib_MS]

Hello @Bruce_Teng,
According to the I3C standard, the bus must remain in the Idle state for at least 1 µs before an IBI can be issued. To ensure this timing requirement is met, the device uses the CLK_SLOW . When an IBI request is pending, the internal counter driven by CLK_SLOW must complete one or more counts before the bus is considered fully idle and the IBI can be generated. As shown the following image obtained from the RM (MCXN236):

Also, in order to support you better, could you provide me the next information?
- Could you please clarify me if you have received any previous support of this specific part MCXN556?
- I am getting troubles to see the image that you shared in your previous post, could you share me it with higher resolution?
- Could you provide me the steps that you made to replicate this behavior?

BR
Habib

[Bruce_Teng]

Hi @Habib_MS 
No, I haven't received any support of this specific part MCXN556

Background:
In our system, MCU play a role of bridge between USB and downstream device (GPUs)
So, MCU charges of forwarding data from USB to GPU or GPU to USB.
Once GPU need to pass data to USB, GPU will arise IBI request, then MCU service it and read data from GPU, then forward it to USB.

Experiment:
Send GetStatus command before every transaction (read/write).
I get GPU information or update GPU firmware to trigger read/write transaction.

Note: I3C IP of GPU is not NXP product

[Bruce_Teng]

In our system, MCU is I3C master and GPU is I3C slave.
So, it seems that we couldn't modify register setting to decide GPU how to detect the bus available condition. right?
If yes, should we focus on GPU behavior?

[Habib_MS]

Hello @Bruce_Teng,

Thank you for your response. Based on your comments, the slave (CPU) does not meet the I3C requirement to keep the bus in the IDLE state for at least 1 µs before issuing an IBI request. Is my understanding correct? If so, this could explain why the master (MCU) is unable to process the IBI.

On the other hand, the AN14434 describes exactly the type of behavior expected for the MCU in your application. I highly recommend reviewing this document to ensure the MCU is working correctly.

Please let me know if you have any further questions.

BR
Habib