QE128 I2C Slave

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

QE128 I2C Slave

604 Views
jconrad
Contributor I

I am working on a project where a QE128 processor is an I2C slave to an MCF52259 MQX master.  The QE must accept one byte of address (index) and either read (back to the master) or write an array of control bytes.  I am currently using the Example 13.6 from Fabio's book, modified to do only Slave and operate in polled mode within the QE main loop.  Scoping the I2C lines shows the Slave Address being ACK'd but the index NAK'd.  If I have the debugger active on the QE, it halts with an illegal BP.  Can you point me in the right direction?

Labels (1)
0 Kudos
4 Replies

421 Views
jconrad
Contributor I

Found the Illegal Breakpoint problem.  The I had not sufficiently modified the example code.  The interrupts were enabled for the the I2C even though I was operating in polling mode.  Communication now takes place between the MCF52259 Master and the QE128 Slave... some of the time.

If I use the command line interface (part of the 52259 project) to "manually" read from  the QE128 Slave, it works fairly well.  But if I have a periodic automatic read (about 1/sec) eventually the communication hangs with the MQX routine mcf52xx_i2c_polled_rx_tx spinning on

      do
      {
         i2csr = i2c_ptr->I2SR;
      } while (0 == (i2csr & MCF52XX_I2C_I2SR_IIF));
I have scoped the SDA and SCL lines and when the hang occurs, stopped both processors.  I have found that the SDA line may be either hig or low, but the SCL is always low and can only be cleared by DISABLING the QE128 I2C.  The QE128 I2C control register is showing TX mode which is reasonable, since at the time it is sending requested data back to the Master.  But why has the QE128 taken over the SCL line which should be under the exclusive control of the Master?  Please help with this as it is critical to release of a product that these devices communicate reliably!

0 Kudos

421 Views
kef
Specialist I

http://en.wikipedia.org/wiki/I%C2%B2C#Clock_stretching_using_SCL

 

Since QE was in TX mode and assuming that code is mostly right, probably master was reading from slave and for some reason your QE code didn't write IIC data register.

0 Kudos

421 Views
jconrad
Contributor I

I have done some experimenting with the QE frequency divider register and found a setting that seems to work.  I think the QE (Slave in TX mode) was preventing the 52259 from clocking.

With the new IIC2Fsetting, the two processors have been communicating for about an hour (two packets per second) without a stall.  Can you advise how to determine the proper settings for the Slave, given the settings for the Master?  It is working, but only by stumbling on a setting that worked.

0 Kudos

421 Views
JimDon
Senior Contributor III

FIrst it would be interesting if you shared that setting with us.

It is possible that the I2C module does this in slave mode so you have time to process the byte / send the next byte, and is waiting for some status bit to be set so it continues on and lets go of the clock.

 

It is also "unusual" that you are doing this in polled mode, I say that because all the examples I have seen for slave are interrupt driven, and probably do  not see this problem.

 

0 Kudos