Can't have SDA completely low at ACK on HAL I2C ,MKV31

[diegocolombo]

Hi to all the people in the community

i have an intermediate level when i check ACK bit in an I2C communication ,with uC sending the correct address slave,

It looks like  after the 8th bit,the master uC , instead of releasing the SDA line, holds it at high level,in conflict with the acknowledging peripheral

low level , :

Notice that if i use the same pins in GPIO bitbang ,everything works as expected.

I decided to use a MKV31F256VL uController in a prototype needing versatile PWM and good clock speed

I had to communicate via I2C  with a RTCC.

I did the same thing in minutes in a previous version using a baseline uC,a MKL15 ,using  Code Warrior 10.5,

The PE component for I2C gave me easily the necessary methods.

With this uC  i had to use KDS._12C_hal

The GenericI2C component seems not completely implemented for this device.So  i tried with a lower level component:fsl_i2C_hal

I used it in a non -OSA project,in a very simple way,not very differently than directly accessing to registers,with no interrupts or semaphores.

  I2C_HAL_SetDirMode(I2C0_BASE_PTR,1);

  I2C_HAL_SetAddress7bit(I2C0_BASE_PTR,0x6E);

  I2C_HAL_SetBaudRate(I2C0_BASE_PTR,60000000,300,0);

  I2C_HAL_Enable(I2C0_BASE_PTR);

  while(1)

  {

        Delay_ms(1);

        I2C_HAL_SendStart(I2C0_BASE_PTR);

        I2C_HAL_WriteByte(I2C0_BASE_PTR,0xAE);

        Delay_ms(1);

   }

The pullup resistors are both 10K.

Many thanks

Diego

[diegocolombo]

Solved,for real, this time

it was absolutely my fault,a wrong assumption

there is a bit that i never used and not present in other Freescale uControllers i worked with (KL family), and i was not aware of its existence

is the bit ODE(OpenDrainEnable) in PCR pin configuration register ,missing in the KLfamily,i assumed erroneously that pin configuration was the same after a rapid glance,and that once choosed an alternate I2C function for the pin ,everything would have been in I2C style

And is clearly showed:

Open drain configuration is valid in all digital pin muxing modes

At my weak defense i could say that no mention to this bit in the whole I2C chapter

and the I2C initialization component does not affects this bit(am i right?)

So i could say

not a bug in the uC,compliant to its reference manual

maybe a lack in library,probably inherited from uC with less features,i dare to signal to the support team

As i told it's mainly my fault

Many thanks again for your help ,Daniel

Diego

[diegocolombo]

Thanky ou David..

i say solved but the problem was only moved to the next bytes

I changed the device,a well kwn 2402 eeprom,and the problem remains.and i think it is something  electrical,not exactly I2C.

In I2C a master,or slave can hold down the SDA or release it to the pullups.

Here there is a kind of electric conflict,it looks the device want to acknowledge,and the master don't release the line.It has no sense to me.

In this moment i have no time at all to go deeper in I2C,that is needed for a secondary feature.

Despite the matter is interesting i have to solve,I would be glad to use quickly some high level component,but it looks that there is no component that can be used easily in a non RTOS project.

I'm here from 7 in the morning,with some rest ,now is 1:22 am,..19 hours more or less

I had to solve or i will drop this project because day are passing by,and this time is not paid at all

[diegocolombo]

Solved,in some way:

I assumed(and many times this could be misleading if left undiscussed) that the 7-bit address in A1 register was non important,because the first byte i send after start will result as address to my I2C slave,i thought that A1 value was just the uC address ,when uCis in slave mode..

Actually it looks that the value in A1 should be related to the byte sent with I2C_HAL_WriteByte:

If the address of the slave device is 0x57(in bits 7:1)   the first data to send using I2C_HAL_WriteByte has to be 0x57 *2=0xAE.

If there is no match the uC marks NACK on the 9th bit.

Shurely, for someone all this sounds natural,but in my primitive acknowledge of I2C,I assumed that the master always puts SDa in Hi-Z at the 9th bit,leaving the slave free to decide wich level put on SDA line.

Can someone explain me how it works in this and other cases?

Many thanks

Diego

[DavidS]

Hi Diego,

I'm not an but have some information that might help you.

MQX-RTOS-Session 11: IC2 Driver|NXP   Good video review of I2C.

High overview of I2C: http://www.mcc-us.com/I2CBusTechnicalOverview.pdf 

Deeper dive into the I2C protocol: http://www.mcc-us.com/i2cHowToUseIt1995.pdf 

Regards,

David