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.
The pullup resistors are both 10K.
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
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
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?