I2C master forces push pull mode high level on SDA during ACK??


mai i ask your help?

I'm using a Freescale MKV31F256 microcontroller as I2C Master,pullup resistors are 10K;

I used low level drivers(Hal) to manage a simple I2C communication with a 24C02 I send START,Address byte,acknowledged,then i send the 2nd byte,and at the 9th clock instead the expected ACK from the device,i have an intermediate level between VCC and VDD,how can this be explained?

If i use the pins as GPIOs ina bitbang I2C everything works correctly. I changed the exernal device with an RTCC,same behaviour.

How can an SDA master pin being able to force an high level?IT should release it or keep it low;

thanks for hints

Reply to
Loading thread data ...

It's a familiar problem when the master drives pins hi and lo instead of Hiz and lo. Chances are their i2c driver is buggy or misconfigured....

Reply to
Johann Klammer

Just solved,

it was absolutely my fault,a wrong assumption but the datasheet did not helped me

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 pin configuration,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

Things are differents..

And is clearly showed: Open drain configuration is valid in all digital pin muxing modes

No mention to this pin in the whole I2C chapter and the I2C initialization component does not affects this bit

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 As i told it's mainly my fault

Many thanks for your hint


Reply to

I was going to suggest looking for something like that -- I'm glad you found the problem yourself.

I call such things "screw the processor bits". It seems like there's a rule out there that they have to be in some seemingly unrelated hardware block and poorly documented, to boot.

Reply to
Tim Wescott

Thanks Tim

Reply to

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.