I2C Acknowledge problem

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

I2C Acknowledge problem

Jump to solution
4,987 Views
ishwarlal
Contributor III

Hi, I am having problem with I2c module, after sending Address byte from MCU the slave is not able to Acknowledge it looks like the Master is not giving line free for slave to acknowledge.

Our scenario:

MCU MK66 (CoreClk180Mhz, Fbus 60Mhz)

IDE Atollic

Slave Mcp4728 (Quad 12Bit DAC)

I2C Baud 100Kbps

Board Custom Board.

Code custom code (parts copied from SDK).

 

In order to test the Hardware connections I wrote a SoftI2CMaster (using Bitbang) and it works fine only the built-in hardware I2C module makes problems.

 

Attached please find the Oscilloscope Screen-shots for software and hardware I2CMaster.

Also the code for both.

 

I have been banging my head since Monday, can anyone please help.

Original Attachment has been moved to: HardI2CMaster.h.zip

Original Attachment has been moved to: SoftI2cMaster.cpp.zip

Original Attachment has been moved to: SoftI2cMaster.h.zip

Original Attachment has been moved to: HardI2CMaster.cpp.zip

Tags (2)
1 Solution
3,757 Views
fjsanchez
Contributor II

I had the same problem when we changed from K64 to K66. The I2C had been working fine with the K64 and KSDK1.3, but when we changed to K66, the I2C stopped working properly (like in your oscilloscope screen-shots, we always got NACK from the external EEPROM). We solved the problem by enabling the open-drain configuration in both SDA and SCL pins:

void init_i2c_pins(uint32_t instance) {
switch(instance) {
   case I2C0_IDX: /* I2C0_IDX */
      /* Affects PORTD_PCR8 register */
      PORT_HAL_SetMuxMode(PORTD,8UL,kPortMuxAlt2);
      PORT_HAL_SetOpenDrainCmd(PORTD,8UL,true);
      /* Affects PORTD_PCR9 register */
      PORT_HAL_SetMuxMode(PORTD,9UL,kPortMuxAlt2);
      PORT_HAL_SetOpenDrainCmd(PORTD,9UL,true);
      break;
   default:
      break;
   }
}

View solution in original post

11 Replies
3,758 Views
fjsanchez
Contributor II

I had the same problem when we changed from K64 to K66. The I2C had been working fine with the K64 and KSDK1.3, but when we changed to K66, the I2C stopped working properly (like in your oscilloscope screen-shots, we always got NACK from the external EEPROM). We solved the problem by enabling the open-drain configuration in both SDA and SCL pins:

void init_i2c_pins(uint32_t instance) {
switch(instance) {
   case I2C0_IDX: /* I2C0_IDX */
      /* Affects PORTD_PCR8 register */
      PORT_HAL_SetMuxMode(PORTD,8UL,kPortMuxAlt2);
      PORT_HAL_SetOpenDrainCmd(PORTD,8UL,true);
      /* Affects PORTD_PCR9 register */
      PORT_HAL_SetMuxMode(PORTD,9UL,kPortMuxAlt2);
      PORT_HAL_SetOpenDrainCmd(PORTD,9UL,true);
      break;
   default:
      break;
   }
}

3,757 Views
ishwarlal
Contributor III

Hi Javier,

I stumbled upon my own thread yesterday and read your answer.

Your tip helped us.

We enabled the Open Drain on I2C pins and it worked like a Charm.

Thanks

0 Kudos
3,757 Views
ishwarlal
Contributor III

hi, Update

attached please find the schematic.

I tried to bridge the (IC805)(ADM2250ARWZ) and tried with different Pull-ups 1K to 10K

but no improvement.But in all hardware test conditions the SoftI2CMaster works fine only the

hardware one not.

I am using I2C to achieve 4x Galvanic Isolated Analog-Outputs, but as I said for tests I just removed the Isolation IC.

Schematic.JPG

Regards

Lal.

0 Kudos
3,757 Views
egoodii
Senior Contributor III

Your text says 100K I2C rate, but your scope shots show closer to 375KHz, and more particularly your selected HW I2C settings are giving only something like 0.6us 'data hold' after falling clock edges, whereas SW is giving more like 1us.  "Fast Mode' of MCP4728 calls for 0.9us 'hold time', and I expect your 'galvanic isolation' degrades that timing margin further.

Your slave 'fails to acknowledge' because it 'fails to recognize' the address.

0 Kudos
3,757 Views
ishwarlal
Contributor III

Hi Earl thanks for your Reply,

Well with the scope shots (I uploaded the wrong ones) sorry for that. Attached please find the Scope shot of 100Kbps and 26Kbps, unfortunately the problem persists. Problem is that I am finding it difficult to set the desired Baud-rate and the required Hold-Times at the same time. Both are interlinked. So I tried a Mul value of 4 and a divider value of 576 (in I2C_F register) which gives 26Kbps baud but no improvement.

HwI2CMaster100Kbps

HwI2CMaster100Kbps.png

HwI2CMaster26Kbps

HwI2CMaster26Kbps.png

0 Kudos
3,757 Views
egoodii
Senior Contributor III

That is certainly both confusing and disappointing.  I agree, the entanglement of 'setup/hold' with 'baud-rate' is certainly 'confusing at best', but it looks like you have certainly tried 'slow enough to make anything happy!'...if 6.8us doesn't work, then we have to assume 'something else'.

I am assuming that 'somewhere to the left' there was either power-up or 'stop' so that we can assume the 'slave' is 'truly idle' coming in.  Otherwise, I've got 'no viable excuse' for NACK...

0 Kudos
3,757 Views
ishwarlal
Contributor III

I am assuming that 'somewhere to the left' there was either power-up or 'stop' so that we can assume the 'slave' is 'truly idle' coming in.  Otherwise, I've got 'no viable excuse' for NACK...

I had same thoughts and tried to send the "General Call Commands" like "Reset" and "Wake-up" but also get NACK on General Call Commands :smileysad:.

0 Kudos
3,757 Views
egoodii
Senior Contributor III

I don't know how any of the actions you listed will specifically net a 'stop' event prior to your 'start'.  Can you do just a start/stop pair before this I2C 'access start' sequence?

0 Kudos
3,757 Views
ishwarlal
Contributor III

Hi Earl,

I tried it in the following Manner.

Power-up/SysReset --> I2CStart --> wait 3Us --> I2CStop --> I2C General Call Reset  --> wait 1ms --> I2C General Call Wake-up --> Write Dac data --> wait 1Sec --> Write Dac data --> wait 1Sec --> Write Dac data --> and so on.

No success. For all I2C transactions I always get NACK.

Just a question, have you yourself worked with MCP4728 in combination to Kinetics Controller or any other controller?

0 Kudos
3,757 Views
egoodii
Senior Contributor III

Sorry, no, not that particular peripheral, but I do use the MK20&22F hardware I2C EXTENSIVELY in a fully-background interrupt and sequence-state-driven process to do all necessary 'One-Wire' activities for such Dallas/Maxim memory and temperature parts as thru the DS2483 'master' interface, and it all works great!

0 Kudos
3,757 Views
ishwarlal
Contributor III

Actually we already used Kinetics Controller together with MCP23017 (12C I/O expander) and it worked fine, some how it is having problem with MCP4728, well I am going to give up on this and may use another Dac or may be chose one with SPI. Any way thanks for your time and effort.

0 Kudos