S32K344 LPI2C0 Transmission Failures

[ArushThomas]

Hi all,
I'm trying to bringup I2C transactions with the S32K344 microcontroller, configured as a Master device. I've configured the pins as follows:

• PTD13 as LPI2C0_SDA
• PTD14 as LPI2C0_SCL
• PTC6 as LPI2C1_SDA
• PTC7 as LPI2C1_SCL

In the LPI2C peripheral configuration, I've set both peripherals to STANDARD mode, MASTER configurations, with an I2C Baudrate of 53083Hz. In firmware, I'm only trying to transmit one byte to Slave Address 0x68.

What I observed is that the LPI2C1 peripheral returns the error code LPI2C_IP_RECEIVED_NACK_STATUS when I call the Lpi2c_Ip_MasterSendDataBlocking() API. This is expected to me, since I don't actually have any slave device connected.

The problem is that the LPI2C0 peripheral behaves differently. It reports the error code LPI2C_IP_TIMEOUT_STATUS on the first call to Lpi2c_Ip_MasterSendDataBlocking(), and reports LPI2C_IP_BUSY_STATUS on subsequent calls. I had expected it to return LPI2C_IP_RECEIVED_NACK_STATUS, the same as the LPI2C1 peripheral.

Upon probing the I2C buses with an oscilloscope, I observed that the LPI2C1 peripheral drives an I2C waveform, with the address '0x68', followed by a NACK Signal. Exactly as expected.
Whereas, the LPI2C0 peripheral does not show any waveforms whatsoever.

Here are the generated configurations for the LPI2C1 peripheral, which does work correctly:

static const Lpi2c_Ip_BaudRateType baudrateParams1 =
{
    LPI2C_MASTER_PRESC_DIV_128, /* Prescaler */
    1U,  /* Clock HI period */
    3U,  /* Clock LO period */
    0U, /* Setup Delay */
    0U,  /* Data Valid */
    1U, /* Clock High HS */
    3U, /* Clock Low HS*/
    2U, /* Setup Delay HS */
    1U /* Data Valid HS */
};
const Lpi2c_Ip_MasterConfigType I2c_Lpi2cMasterChannel1 =
{
    /* Slave address */
    0U,
    /*10-bit address */
    FALSE,
    /* Operating Mode */
    LPI2C_STANDARD_MODE,
    /* Baudrate parameters */
    &baudrateParams1,
    /* Pin Low Timeout */
    0,
    /* Bus Idle Timeout */
    0,
    /* Glitch Filter SDA */
    0,
    /* Glitch Filter SDA */
    0,
    /* Master code */
    0U,
    /* Transfer Type */
    LPI2C_USING_INTERRUPTS,
    /* Dma Tx channel */
    0,
    /* Dma Rx channel */
    0,
    /* Master Callback */
    NULL_PTR,
    /* I2c Master Callback Parameter */
    0,
    /*  Master State index */
    1
};

Here are the generated configurations for the LPI2C0 peripheral, which does not work correctly:

static const Lpi2c_Ip_BaudRateType baudrateParams0 =
{
    LPI2C_MASTER_PRESC_DIV_128, /* Prescaler */
    1U,  /* Clock HI period */
    3U,  /* Clock LO period */
    0U, /* Setup Delay */
    0U,  /* Data Valid */
    1U, /* Clock High HS */
    3U, /* Clock Low HS*/
    2U, /* Setup Delay HS */
    1U /* Data Valid HS */
};
const Lpi2c_Ip_MasterConfigType I2c_Lpi2cMasterChannel0 =
{
    /* Slave address */
    0U,
    /*10-bit address */
    FALSE,
    /* Operating Mode */
    LPI2C_STANDARD_MODE,
    /* Baudrate parameters */
    &baudrateParams0,
    /* Pin Low Timeout */
    0,
    /* Bus Idle Timeout */
    0,
    /* Glitch Filter SDA */
    0,
    /* Glitch Filter SDA */
    0,
    /* Master code */
    0U,
    /* Transfer Type */
    LPI2C_USING_INTERRUPTS,
    /* Dma Tx channel */
    0,
    /* Dma Rx channel */
    0,
    /* Master Callback */
    NULL_PTR,
    /* I2c Master Callback Parameter */
    0,
    /*  Master State index */
    0
};

The only difference between the two appears to be the 'MasterStateIdx' parameter of the 'Lpi2c_Ip_MasterConfigType' structs. I'm also attaching the whole bringup project.

Kindly do help resolve the error. Why does the LPI2C0 peripheral behave differently from the LPI2C1 peripheral?

For added clarity; I have been able to successfully interface with an I2C slave using the LPI2C1 peripheral, and have failed to do so with the LPI2C0 peripheral. I've been able to replicate these problems on a custom PCB, as well as S32K3X4EVB-T172 SCH-53148 REV B2 development board.

[VaneB]

Hi @ArushThomas 

Just to confirm, on both the custom PCB and the S32K3X4EVB‑T172, did you connect the appropriate pull‑up resistors required for the I2C lines? On the EVB, pull‑ups are already populated for PTC6 and PTC7, as shown in the board schematic. However, PTD14 and PTD13 do not include onboard pull‑ups, so external pull‑ups would be required if you use those pins for I2C.

BR, VaneB

[ArushThomas]

Yes, we did connect external pull-ups of 10 kilo-ohms. The oscilloscope shows that PTD13 and PTD14 have a constant voltage of ~3.3 volts.

[VaneB]

Hi @ArushThomas 

I currently do not have an S32K3X4EVB‑T172 with me, so I performed some tests using the S32K344MINI‑EVB and the S32K3X4EVB‑Q172, along with the attached .mex and main.c files.

On my end, LPI2C0 already returns LPI2C_IP_RECEIVED_NACK_STATUS when calling Lpi2c_Ip_MasterSendDataBlocking(). Could you please run the same setup on your side and let me know if you observe any differences in behavior?

Also, please note that on the S32K3X4EVB‑T172 the PTD13 pin is connected to the TJA1103 transceiver, which may affect its behavior. On the boards I used for testing (S32K344MINI‑EVB and S32K3X4EVB‑Q172), this pin is not connected in the same way. Therefore, there is a possibility that we may observe different behavior on your EVB due to this hardware difference.

[ArushThomas]

Hi Vane, thanks for your example!

Running it on Arrow's SEED-S32K3B_CORE, I was able to find that LPI2C0 worked correctly on PTD13 and PTD14.

I found on our S32K3X4EVB-T172, that the PTD13 is connected to Pin#2 of the TJA1103A PHY. I imagine that's what was causing interference there.

Finally, I found a soldering defect on our custom PCB. So there was discontinuity between my pullups and the MCU pins, resulting in the 'BUSY' error code.

Reworking our PCB solved the issue.
Thanks for your help!

[VaneB]

Hi @ArushThomas 

Thank you for your feedback. I am glad to hear that the problem has been resolved.