Hi,
I've recently been working with I2C peripherals on imxrt1176 uc. I2C5 is connected to a PMIC and it works great. There are no issues with the I2C5 peripheral.
However, I2C3 and I2C4 are routed to the external connectors to our board so that we can connect something over I2C to our board and control it.
Unfortunately, I was not able to get either of them working. The only thing I could see was a 1 CLK pulse whenever LPI2C_MasterStart(...) was called. The length of the pulse is affected by the baudrate set for the given I2C instance, but still, no data visible on SDA.
Picture for reference: (Yellow is SCK and Green is SDA)
I'm able to read the kStatus_LPI2C_ArbitrationLost after the above transaction is done. There is nothing else on the line that could disrupt the transaction.
Now, when I route the I2C4 pins from GPIO_DISP_B2_12 and GPIO_DISP_B2_13 to GPIO_AD_24 and GPIO_AD_25, the transaction is valid and I can see both SCK and SDA, transmission is valid.
For the pinout configuration I used config tool from MCUXpresso. Generated configuration was generated and put into pin_mux.c and pins were initialized.
When it comes to the source code used, I executed some ordinary example code as below:
if (kStatus_Success == LPI2C_MasterStart( LPI2C4, i2c4_ext_address, kLPI2C_Write))
{
/* Check master tx FIFO empty or not */
LPI2C_MasterGetFifoCounts(LPI2C4, NULL, &txCount);
while (txCount)
{
LPI2C_MasterGetFifoCounts(LPI2C4, NULL, &txCount);
}
/* Check communicate with slave successful or not */
if (LPI2C_MasterGetStatusFlags(LPI2C4) & kLPI2C_MasterNackDetectFlag)
{
return kStatus_LPI2C_Nak;
}
reVal = LPI2C_MasterSend( LPI2C4, &i2cExtAddrArray[0], sizeof(i2cExtAddrArray[0]));
if (reVal != kStatus_Success)
{
if (reVal == kStatus_LPI2C_Nak)
{
LPI2C_MasterStop( LPI2C4 );
}
}
}
Now the pinout configuration part comparison:
- The working pinout is:
- Not working pinout is:
EDIT 1:
As it tuned out, fsl_iomuxc.h generates slightly different configuration for I2C4 depending on what pins it is defined.
The code snippet below is for the configuration that does not work, and on the 4th position we can see 0x01 value there. It is responsible for setting the inputDaisy pin configuration.
#define IOMUXC_GPIO_DISP_B2_12_LPI2C4_SCL 0x400E8244U, 0x6U, 0x400E85C4U, 0x1U, 0x400E8488U
Whereas for the configuration that was set on different pins (the ones that I2C4 actually works) it looks like this:
#define IOMUXC_GPIO_AD_25_LPI2C4_SDA 0x400E8170U, 0x9U, 0x400E85C8U, 0x0U, 0x400E83B4U
After changing that inputDaisy value for the not working configuration, I got some clocking action on the SCK pin, but unfortunately still no data on the SDA pin
On the image below you can see the issue described above, the SDA data should send 0x25.
Counter example from the I2C4 setup on pins that work:
There is no source code difference between these 2 examples besides the configuration part. I could not see any mention in the rt1176 RM saying that I2C4 should be configured differently than I2C5 for example.
Summary:
Honestly it feels extremely strange and I have no idea where the issue could be.
There are no issues hardware-wise as the communication path from BGA uC pins leads directly to the output via some pull up resistors on the SDA and SCK lines.
There is also an issue of this configuration generation that is slightly different (inputDaisy configuration) depending on the pinout. This might be SDK issue I think or there is some hidden logic/behavior behind it that I'm unaware of.
