iMXRT1176: I2C3 and I2C4 not working with default settings - microcontroller design error?

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

iMXRT1176: I2C3 and I2C4 not working with default settings - microcontroller design error?

3,604 Views
mimlo
Contributor III

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)
mimlo_0-1715074715095.png

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:

mimlo_5-1715075897506.png

- Not working pinout is:
mimlo_6-1715087683177.png

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.

mimlo_7-1715088205635.png

Counter example from the I2C4 setup on pins that work:

mimlo_8-1715088265326.png

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.

Tags (2)
0 Kudos
Reply
22 Replies

2,919 Views
Pavel_Hernandez
NXP TechSupport
NXP TechSupport

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: 

Pavel_Hernandez_0-1717170174585.png

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

 

 

0 Kudos
Reply

2,813 Views
mimlo
Contributor III

Hello @Pavel_Hernandez,

I downloaded your example and what I saw was that you are using I2C5 and I2C1 in the example. I also do not see the pins I mentioned I had problems with being used. Is this the correct version of the project you shared?

Ideally I would need to have the exact set of pins (GPIO_DISP_B2_12 and GPIO_DISP_B2_13) for the I2C4 peripheral. Would be able to cross check the whole initialization and setup code?

0 Kudos
Reply

2,784 Views
Pavel_Hernandez
NXP TechSupport
NXP TechSupport

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.

Pavel_Hernandez_0-1717514877696.png

Best regards,
Pavel

0 Kudos
Reply

2,780 Views
mimlo
Contributor III

Ok, I missed that during searching the code for keywords
Does it require the second board at all or it was intended to work within the same board by connecting the 2 peripherals together in a loopback system?

0 Kudos
Reply

2,767 Views
Pavel_Hernandez
NXP TechSupport
NXP TechSupport

Hello, I used the example to test it, and yes still similar to this, needs to use the same board for the communication loop.

[Example original explanation] To make lpi2c example work, connections needed to be as follows:

LPI2C3 SCL(J9-4) --> LPI2C5 SCL(J10-20)
LPI2C3 SDA(J9-2) --> LPI2C5 SDA(J10-18)

Best regards,
Pavel

0 Kudos
Reply

2,961 Views
Pavel_Hernandez
NXP TechSupport
NXP TechSupport

Hello, I apologize for the late response, I'm researching more information with the SDK team. When I have more details, I will contact you.

Best regards,
Pavel

0 Kudos
Reply

2,981 Views
mimlo
Contributor III

@Pavel_Hernandez
You are definitely not able to test the I2C4 on the pinout I mentioned earlier?
As I pointed out, I2C3 works correctly after setting the SION and open-drain values properly, but the same pinout configuration still does not work for these pins for I2C4. In the meantime, when I change the I2C4 to use other set of pins, it works out fine.
Still it seems to me like some SDK bug in terms of generation of code for the pinout configuration or microcontroller design error, which would be a serious issue.

Please let me know what else can be done to help resolve it.


Thanks,
Michael

0 Kudos
Reply

3,222 Views
Artos
Contributor I

@Pavel_Hernandez 

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

Artos_3-1715950338041.png

Artos_4-1715950387409.png

 

Artos_2-1715950222451.png

 

 

0 Kudos
Reply

3,242 Views
muratokusluk
Contributor II

I encountered the same problem. Is there any progress?

0 Kudos
Reply

3,134 Views
mimlo
Contributor III

Making sure that both SION field and open-drain field are set for the I2C3 peripheral resolved this issue for me, but only for this particular peripheral and set of pins.

0 Kudos
Reply

3,265 Views
Pavel_Hernandez
NXP TechSupport
NXP TechSupport

Hello, I am following your case I´m researching more information, but I see you have a confusion and maybe this table clarifies that.

Pavel_Hernandez_0-1715899903724.png

Pavel_Hernandez_10-1715900944780.png

Pavel_Hernandez_9-1715900924926.png

Pavel_Hernandez_13-1715901103161.png

Pavel_Hernandez_11-1715901045261.png

12.4.6.288 SW_PAD_CTL_PAD_GPIO_DISP_B2_12 SW PAD Control

 

Pavel_Hernandez_6-1715900630930.png

Pavel_Hernandez_7-1715900785396.png

Pavel_Hernandez_5-1715900621531.png

The value deepens by config tool.

Pavel_Hernandez_14-1715901294648.png

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

0 Kudos
Reply

3,098 Views
mimlo
Contributor III

Hi @Pavel_Hernandez

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:

mimlo_0-1716291644394.png
mimlo_1-1716291682632.png
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.

0 Kudos
Reply

3,279 Views
Pavel_Hernandez
NXP TechSupport
NXP TechSupport

Hello, did you use an example and modify this, if yes could you let me know what example you based on? this is for get the same environment to replay the issue.

Best regards,
Pavel

0 Kudos
Reply

3,275 Views
mimlo
Contributor III

Hi,
Sorry for not posting the example previously. I simply forgot to do that
FYI: This is SDK version I'm using

mimlo_0-1715842451605.png

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

0 Kudos
Reply

3,315 Views
Pavel_Hernandez
NXP TechSupport
NXP TechSupport

Hello, let me test it on my side, but I reviewed the RT1170 EVK only has the Arduino output, the I2C3 available. For the other signals the I2C4 GPIO_DISP_B2_12 only one can be routed to these headers.

I will try this I2C3 on the headers.

Best regards,
Pavel

0 Kudos
Reply

3,305 Views
mimlo
Contributor III
In my case,
I2C4 operates on (SCL) GPIO_DISP_B2_12 and (SDA) GPIO_DISP_B2_13
and
I2C3 operates on (SCL) GPIO_DISP_B1_02 and (SDA)
GPIO_DISP_B1_03
0 Kudos
Reply

3,330 Views
mimlo
Contributor III

@Pavel_Hernandez 
Would it be possible for you to try reproduce this particular issue on the hardware with iMXRT1176 uc?

0 Kudos
Reply

3,411 Views
nickwallis
Senior Contributor I

it is worth checking that both pins are defined as open drain (with internal pullup, if you don't have them externally) and also that the SION fields are also enabled.

3,135 Views
mimlo
Contributor III

Hi,
In general, your were correct.

However, I'm still not sure why the config tool greyed out open drain configuration for me when I was setting the pinout configuration for I2C peripheral.

After looking into the pinout once again, I regained the ability to change this open-drain field to Enabled.
I'm not sure what caused this issue but I'm glad it is resolved now.

What still remains a mystery for me, is the fact that the very same configuration on other set of pins for I2C, worked correctly even though the open-drain option was not set

Thank you all for your help, I appreciate it!

Best regards,
Michal

0 Kudos
Reply

3,391 Views
mimlo
Contributor III

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:
mimlo_0-1715321812016.png

 

#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).

0 Kudos
Reply