Hi 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
I2C master forces push pull mode high level on SDA during ACK??
Started by ●January 8, 2016
Reply by ●January 8, 20162016-01-08
On 01/08/2016 12:23 PM, blisca wrote:> Hi > > 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 >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 by ●January 8, 20162016-01-08
Il 08/01/2016 15:50, Johann Klammer ha scritto:> On 01/08/2016 12:23 PM, blisca wrote: >> Hi >> >> 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 >> > 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....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 Diego
Reply by ●January 8, 20162016-01-08
On Fri, 08 Jan 2016 17:06:11 +0100, blisca wrote:> Il 08/01/2016 15:50, Johann Klammer ha scritto: >> On 01/08/2016 12:23 PM, blisca wrote: >>> Hi >>> >>> 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 >>> >> 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.... > > > 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 > > DiegoI 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. -- www.wescottdesign.com
Reply by ●January 11, 20162016-01-11
Il 08/01/2016 21:46, Tim Wescott ha scritto:> On Fri, 08 Jan 2016 17:06:11 +0100, blisca wrote: > >> Il 08/01/2016 15:50, Johann Klammer ha scritto: >>> On 01/08/2016 12:23 PM, blisca wrote:>>>> 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?>> 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 hints >> >> Diego > > 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. >Thanks Tim
