Hi,
I am working in a product that runs with a LPC11E68. I noticed that the device hung sporadically beacuse of a i2c communication. Debuging into, I found out that the i2c returns a STA value of 0x58:
This is a return STA value only available in receive mode. But my transmision was configured only to transmit frame. The I2CM_XFER_T *xfer was configured with:
xfer.slaveAddr = I2C_SLAVE_MCP_ADDR;
xfer.options = 0;
xfer.status = 0;
xfer.txBuff = txBuffer;
txBuffer[0] = I2C_MCP_CONFIG_POINTER;
txBuffer[1] = I2C_MCP_CONFIGURATION_VALUE;
xfer.txSz = 2;
xfer.rxBuff = rxBuffer;
xfer.rxSz = 0;
That means, it should be imposible to be at that state. Puting a breakpoint in the LPCopen i2c handler, I noticed that the code pass into the following point of the :
/* Rx handling */
case 0x58: /* Data Received and NACK sent */
case 0x50: /* Data Received and ACK sent */
*xfer->rxBuff++ = pI2C->DAT; //Breakpoint
xfer->rxSz--;
The firmware stops at that breakpoint when it hangs, but the xfer->txSz was still with 2 value. That means it hadn't started the transmision. And what's worse, entrying in that STA handler "imposible" value, because xfer->rxSz had a 0 value, the decrement pass xfer->rxSz to 65535 causing a big damage in the memory
That code works without any IRQ. It is just a simple Chip_I2CM_XferBlocking() call. I fixed it just checking first a none 0 xfer->rxSz value before decrement.
/* Rx handling */
case 0x58: /* Data Received and NACK sent */
case 0x50: /* Data Received and ACK sent */
if (xfer->rxSz) {
*xfer->rxBuff++ = pI2C->DAT;
xfer->rxSz--;
}
This code does not hinder, but the peripheral must not enter into this STA value without starting a receive transmition, and that is why this extra code should not be necessary. I consider the LPCopen code well written, and seems to be a hardware issue or something I missunderstand.
I am scratched with this behaviour, and I would like if somebody has had some similar experience.
Thank you
