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.
Hello, this test was done in the EVKC. Both I2C3 and I2C4 can work normally.
I2C3 pin: GPIO_DISP_B2_10 and GPIO_DISP_B2_11.
I2C4 pin: GPIO_DISP_B2_12 and GPIO_DISP_B2_13.
I do some rework on board, SDK version is 2_15_0.
Picture attached below shows the log of test demo:
I attached test project, pin configuration can be check in project, I2C b2b test also done and can work normal.
Place grey out in config tool is because of the difference of pad. DISP_GPIO_DISP_B2 and DISP_GPIO_DISP_B1 are different pad and the control of them is different too.
Best regards,
Pavel
Hello, I reviewed the code and I forgot to mention it in advance change these places from I2C3 to I2C4 and the project can also work normally.
Best regards,
Pavel
I have a solution for your questions.
Automatic value assignments of the basic parameters required for I2C3 can be configured manually via MCUXpresso (Please be care your developments).
When using I2C3 or another peripheral, please check the "Direction", "Software Input On", Pull/up/down config", "Pdrv config", "Keeper", "Open drain" in the "Routing Details" section in the "Pins" section. "Reprogram it from the beginning, taking into *** the situations.
*** If you don't using this modes, you already cannot see "IOMUX_Set_PinConfig" ...
Thanks.
-Artos
Hello, I am following your case I´m researching more information, but I see you have a confusion and maybe this table clarifies that.
12.4.6.288 SW_PAD_CTL_PAD_GPIO_DISP_B2_12 SW PAD Control
The value deepens by config tool.
Edit: I reviewed the example however the EVK has the LPI2C3 available on the Arduino headers, and this works as expected. Could you review your design PCB.
Best regards,
Pavel
Making sure that both SION field and open-drain field are set for the I2C3 peripheral resolved this issue for me, but only for I2C3 peripheral. I2C4 still does not work.
All the settings are the same for I2C3 and I2C4, besides the ones that are greyed out for I2C4 as shown below:
There are some differences between I2C3 and I2C4 but they are greyed out, any idea why that is? What else could be wrong here? Should I set the greyed out options manually?
My thinking is, that when something is greyed out, it's not available for change.
Currently, for I2C4 there is a continuous clock after send transaction, and it does not stop at all.
When pinout is changed to the one mentioned in my previous post, it works correctly. What could be the issue here?
Is there some bug in the SDK or in the uc design? It seems serious.
Hi,
Sorry for not posting the example previously. I simply forgot to do that
FYI: This is SDK version I'm using
When it comes to the example I tried this one:
evkmimxrt1170_lpi2c_polling_b2b_master_cm7
However, it did not work as well, so I only made sure to move this code to my project code for additional testing and the result was the same, as expected.
And here is the code that I'm running:
const uint32_t LPI2C4_BAUDRATE = 100000;
const uint8_t i2c4_ext_address = 0x25;
size_t txCount = 0xFF;
status_t reVal = kStatus_Fail;
uint8_t i2cExtAddrArray[5] =
{
0x33, 0x44, 0xAA, 0xFF, 0x01
};
lpi2c_master_config_t masterExtConfig;
LPI2C_MasterGetDefaultConfig( &masterExtConfig );
// Change the default baud rate configuration
masterExtConfig.baudRate_Hz = LPI2C4_BAUDRATE;
// Initialize the LPI2C master peripheral
LPI2C_MasterInit( LPI2C4, &masterExtConfig, CLOCK_GetFreq(kCLOCK_OscRc48MDiv2));
while (1)
{
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 );
}
}
}
}
The above code snippet is part of main, of course I do have board pin init and clocks on the top.
This is the code that either works or does not depending on the I2C pins that are used for the peripheral.
No other change was required in the snippet above to see this strange behavior, only underlying pinout change resulted in I2C working or not.
Please do let me know if you actually require exact copy of the code I'm running or the above is entirely sufficient on its own.
Thanks,
Michal
Hi @nickwallis ,
The pins are configured correctly as open drain. Additionally there are also pull-up resistors on the SCK and SDA lines.
masterConfig->pinConfig = kLPI2C_2PinOpenDrain;
The SION bit value is also set as shown below:
#define IOMUXC_GPIO_DISP_B2_12_LPI2C4_SCL 0x400E8244U, 0x6U, 0x400E85C4U, 0x1U, 0x400E8488U
#define IOMUXC_GPIO_DISP_B2_13_LPI2C4_SDA 0x400E8248U, 0x6U, 0x400E85C8U, 0x1U, 0x400E848CU
The worrying part here is only the 4th value presented in the define, but it was already described by me in the original post.
Are you able to confirm whether this particular peripheral on these particular pins work for you?
I could share the code with you that I used.
Bear in mind that the behavior is extremely strange and it does not work on one set of pins that the RM say that should work.
It is either some bug in uC design or config tool generates code with erroneous configuration.
Either way, it seems an urgent issue, because the code was taken from the existing SDK example and only pinout and peripheral number was adjusted. The whole purpose of this i2c module in SDK is to work seamlessly no matter the peripheral number and pins (assuming it is correctly set and supported by uC, which in this case is true).
