DM6435 I2C lockup

Problem appears to be related to changing the clock rate after the first setup.  We have a slower speed devices on the bus that can ignore high speed traffic.  When we change the clock speed, we get erratic results after that.  I have tried putting delays in and checking all the status bits I can find but after a clock speed change the I2C controller will transmit erroneous data and/or stop clocking the bus.

Hi

I am using a DM648 EVM and have the same problem (Bus Busy). I am running the DM648_NORWriter utility and it fails on the first I2C write:

  // Set board-level muxes for EMIFA access
  status = I2C_ECP_write(I2C_ECP_VMX_REG,0x20);  //??ejp Won't need for VPS
  if (status != E_PASS)
  {
    DEBUG_printString("Write to ECP EMIF/VP control register appears to have failed.");
    return;
  }

I added the code below in the DEVICE_I2C0Init() function and it traps there. The ICSTR register is 0x1040 (1 is the Bus Busy (BB) bit and 4 is a reserved bit??).

  status = I2C0->ICSTR;  //??ejp Added this.
  if(status & I2C_ICSTR_BB_MSK)
  {
      DEBUG_printString("DEVICE_I2C0Init(): I2C bus is busy.\r\n");
  }

The DM648_NORWriter utility sometimes works[:D] and sometimes does not. [:@]

Eric Bryan said:

We had an issue with the I2C locking up.  After an error the clock is high and the data is low.  We cannot clear this by using the RST bit in ICMDR. 

When you put the I2C in reset that will cause the I2C module to "release" both the SCL and SDA lines.  If you still see SDA held low after you reset the I2C that indicates that one of the slaves is holding SDA low.  That might happen if one of the slaves was "confused" on the clock and thought that it was trying to transmit a zero.  It continues to hold SDA low waiting for the next SCL clock which never comes, i.e. it is out of sync with the transfer.  Is there noise on the line, improper voltages, non-monotonic edges, or otherwise to mess things up?

Eric Bryan said:

We think the issue was writing to the device before the BB was clear. 

1. Can someone confirm that this effect is caused by using the device before BB is clear?

2. What is a definitive way, short of power cycling the DSP, to clear such an error?

It sounds like you need to reset the slave(s) to release SDA.  Also, you need to find the root cause of how things got out of sync to begin with.  That should not happen.

Brad

With just one peripheral, I was able to change speeds and keep communications working.  So it doesn’t appear to be changing speeds that is really the issue or maybe not the sole issue.

I generated the problem talking to an MSP430F2013.  I disconnected the MSP430 physically and held the one peripheral on the board in reset.  When the problem occurred the clock line stayed high and the data line stayed low even after all external devices were disconnected and the on-board peripheral was in reset.  No clock is output after I2C resets and transmit attempts.  The data line does appear to move somewhat every transmit attempt.  When in this state, DSP reset (from the emulator) does not clear the problem.  The only way to clear is to power the DSP down. 

Using the PSC to DISABLE (and/or SWRSTDISABLE I tried them both) followed by ENABLE does not clear the problem.  I don’t know if it’s a different problem or an indication of the condition, but the PSC sequence results in a crash of the emulator session with a “stall” a short time later.  I am using the sequence:

            dm6435_PSC_changeState( 18, PSC_DISABLE );           // tried this with just DISABLE, just SWRSTDISABLE and both before re-ENABLE

    dm6435_PSC_changeState( 18, PSC_SWRSTDISABLE );

            dm6435_PSC_changeState( 18, PSC_ENABLE );

I will check today for over- and undershoot in the clock and data lines and see if this is possibly a latch-up problem.  I will also force a hardware reset on the DSP rather than use the emulator command and see if that clears it.  I may also try using just two high speed devices and talking to one at low speed and the other at high speed and see if that induces the problem.

One additional note-- the last transmission from the DSP is a write sequence.  The address byte is correct but the data byte is not.  The data byte has extraneous ones in it (for example, the data should be 0x80 but comes out 0x85).  I checked the transmited data passed to the I2C with the emulator and it appears correct (0x80 in this example).  After one or more of these failed transmits the I2C locks up as stated above.  The extra ones in the transmission don't appear to be contention.  They are sharp and, if the bus does not lock, the transmit sequence is repeatable. 

I reduced the strength of the pull-ups (made the resistance higher) on the I2C lines and that seems to prevent the lockup-condition from happening.  I am still concerned that we have the potential to induce an error on the I2C that cannot be cleared without power cycling.

I've never seen the DSP hold on to the I2C lines after resetting the I2C peripheral.  What about doing a device reset?  Even if you don't have a reset button on your board you can use CCS and go to Debug -> Advanced Resets -> System Reset (I think that's what it's called -- I don't have CCS open this minute).  That particular reset will do a device level reset not just a CPU reset like you would get by doing Debug -> Reset.  Does that clear the condition?  If not, I find it hard to believe that the DSP is actually holding the line.

System reset does clear the problem.  I had another design where we still had the smaller value pu resistors and it would go into the same state.  System reset cleared the issue but we have to reconnect the emulator and reload the application.  The root cause is somehow related to the pu resistors.  Changing the pu resistors to a higher value seems to prevent this condition from occurring.

Eric Bryan

Can you post some screenshots of your I2C signals?  I'd like to checkout rise/fall times, signal integrity, etc.