I2C on KDS and configuring the component

[Kewal]

Hi,

I was actually trying to configure the I2C component through KDS and I have schematics for the hardware as below.

So, I am trying to configure the address of slave in the component so My KDS/PE component config is somewhat as below

While I want to start sending data to I2C, I am still thinking more configuration is required or I am really missing some fundamentals of getting the I2C to work.

With the FreeRTOS and MAX7304 itseems to be a maze to get it working. But, while seeing the demo app it looks like a cakewalk. Please provide inputs on configuring the I2C using KDS.

[Jorge_Gonzalez · Accepted solution]

Hello Kewal Deshpande:

In your case the Kinetis MCU will be the I2C master, so there is no need to create or enable any Slave Configurations. Also, the slave address must be specified in the Master Configuration. See the screenshot below:

Now regarding on the use of the I2C driver APIs, you can refer to the KSDK example projects. For example for FRDM-K64F:

C:\Freescale\KSDK_1.3.0\examples\frdmk64f\driver_examples\i2c

C:\Freescale\KSDK_1.3.0\examples\frdmk64f\demo_apps

Let me know if you have any questions.

Regards!,
Jorge Gonzalez

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[Kewal]

Hey Jorge,

thanks for the inputs. I have configured as you mentioned.

I have another problem with respect to I2C where

  reg_buff[0]= 0x40;

  data_Buff[0]= 0x10;

  I2C_DRV_MasterSendDataBlocking(I2C_FOOTSWITCH_INSTANCE, &footSwitch, reg_buff, 1, data_Buff, 1, 1000);

  xTaskDelay(40);

During the call, I2C_DRV_MasterSendDataBlocking I am landing at Error hook,.. If I am debugging and gettting into the HAL call, I am able successfully write multiple bytes.

There is some clocking issue here,.. Also i noticed that If I clock at 120 Mhz I get into this problem. I am not able to see if the clock works at default speed like 20Mhz as per the tower K64 clocking.

Any inputs on this regard is highly appreciated.

Thanks,

Kewal

[Jorge_Gonzalez]

Hello Kewal:

Sorry, I did not understand your issue, could you provide more details?

What do you mean with

I am landing at Error hook,

and

If I am debugging and gettting into the HAL call, I am able successfully write multiple bytes.

As a side note, when debugging I2C problems, it is very convenient to have a scope or logic analyzer at hand, to see what is happening in the bus.

Regards!

Jorge Gonzalez

[Kewal]

Jorge,

Ok to explain the problem..

To configure a I2C based port expander we are writing to the different registers multiple time using the below source code

  reg_buff[0]= 0x40;

  data_Buff[0]= 0x10;

  I2C_DRV_MasterSendDataBlocking(I2C_FOOTSWITCH_INSTANCE, &footSwitch, reg_buff, 1, data_Buff, 1, 1000);

  xTaskDelay(40);

  reg_buff[0]= 0x43;

  data_Buff[0]= 0x10;

  I2C_DRV_MasterSendDataBlocking(I2C_FOOTSWITCH_INSTANCE, &footSwitch, reg_buff, 1, data_Buff, 1, 1000);

  xTaskDelay(40);

so our board is clocked at 120MHz (K64 processor board). When we put breakpoint before every I2C_HAL_WRITE we are able successfully write to the register and everything works properly.

When we do not put breakpoint but just run the application. As we are running safeRTOS which is nothing but freeRTOS it gets to an errorhook.

So we need to understand how the timeout of I2C_DRV_Mastersendblockingdata works and also the xTaskDelay which is used in I2C example code provided.

hope it helps.

Thanks,

Kewal

[Kewal]

Jorge,

The error hook issue was due to insufficient task memory alloted in FreeRTOS so I have come out of that problem.

Well, Now since I am able to write to I2C everything is good except writing to few registers in the port expander. any hints or ideas where I might be going wrong. I am receving a NACK from the remote I2C device.

thanks,

Kewal

[Kewal]

Right now,. I was able to dig deeper into the problem. K64 processor connects to a porttexpanderMAX7304 over I2C at 400Khz.

My processor is clocked at 120Mhz, and the bus clock at 60 and the external at 40 Khz.

I am having the clock stretching issue, any idea on how to over come it.. do we need to play with the pullup resistor and capacitance on SCL line.

Attached is the snapshot of the SDA and SCL lines and the stop bit before receiving the data,.. only address and command can be seen.

Thanks,

Kewal

[Jorge_Gonzalez]

Hello Kewal:

It's good to know you found the issue about task memory.

About your latest question, if you are expecting to receive some data from the slave, then you should call a Receive API: I2C_DRV_MasterReceiveDataBlocking or I2C_DRV_MasterReceiveData. I don't know how your port expander works but these receive APIs expect the next parameters:

instance: I2C module instance used.

device: Pointer to I2C device structure (slave address + baudrate).

cmdBuff: Pointer to the buffer containing command data to send.

cmdSize: Size in bytes to send from the cmdBuff.

rxBuff: Pointer to a buffer to store received data.

rxSize: Number of bytes to receive.

In your case I suppose you need to send the 0x35 as part of cmdBuff, with a size of 1.

Regards!

Jorge Gonzalez

[Kewal]

Jorge,

I am not trying to read, but I am trying to write. Just that the data does get sent out,.. clock stretching would happen and the stop bit is detected.

As you can see above in the attached image, only the address and cmd buffer makes it out onto the SDA, but the data doesnt get written but the driver returns a NACK(master-> status 5) while on the analyzer we could see that there is a stopbit arriving while the clock is stretched out.

So I was thinking that if we slow down the external bus clock, it might help like from currently at 40Mhz to 20Mhz.... What are your thoughts on the same? Do you suggest anything else or issues with driver or we should try to look into.

Thanks,

[Jorge_Gonzalez]

Hi Kewal:

Sorry, I misunderstood and thought you wanted to receive data.

Your image shows an ACK bit after sending the command byte (0x35), but then according to your description the driver is detecting a NACK instead. I would first try with a lower I2C frequency (e.g. 100 kHz).

About the external bus clock, do you mean the flexbus clock? What are you doing with Flexbus? That should not interfere, but in any case I would also remove or comment out any extra code/drivers and temporarily test only the I2C part.

Regards!

Jorge Gonzalez

[Kewal]

Jorge,

We had this problem resolved by looking at one of your other posts. I am just trying to give a thumbsup here for anybody with the same issue.

https://community.freescale.com/thread/334196

https://community.freescale.com/thread/334392

But In our case the situation worsened because we used a saleae analyzer which spoon feeds us with a digital ouput and dint bother to have a look at the analog output.

We had to finally configure the SDA and SCL lines for opendrain and the fsl IIC driver worked straight away. I was wondering how could we miss enabling the opendrain through KDS but then we figured out we dont have an option to enable it through KDS.

but as a last question, is there anyway that the pin can be configured to be opendrain through KDS as i am not able to do through pin_mux :: pinsettings as well.

Thanks,

Kewal

[Jorge_Gonzalez]

Hello Kewal:

It's good to know you found the root cause. And you are right about the logic analyzer, it can hide a key signal behavior that should lead to the resolution of these issues. Thank you for sharing your findings.

About the Open Drain setting, actually you should have the option in the PinSettings component, under the Functional Properties. Can you see that tab?

Regards!

Jorge Gonzalez