Bug in I2C driver lpc17xx_i2c.c

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

Bug in I2C driver lpc17xx_i2c.c

254 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by jeffaroo on Fri Feb 07 21:24:10 MST 2014
I don’t know the correct place to report bug in the LPC1700CMSIS Standard Peripheral Firmware Library, but this seems as good as any...

I’ve been having a problem with generating the STOP condition when sending multiple i2c packets *immediately* following each other using the lpc17xx_i2c.c driver in polling mode.  The STOP condition is correctly generated for each packet when there is a very small pause between packets, but without the pause only the last packet generates the STOP condition.

Looking at the I2C_Start() function I see that the STOP flag is cleared by setting the the I2C_I2CONCLR_STOC bit (bit number 4) in the I2C Control Clear register (I2CONCLR).

I2Cx->I2CONCLR = I2C_I2CONCLR_SIC|I2C_I2CONCLR_STOC|I2C_I2CONCLR_STAC;


However, according to the the LPC176x manual there is *no* STOP clear bit in the I2CONCLR register.  Bit number 4 (where you would expect the stop clear bit to be if there was one) is *reserved* and should *not* be set. So the code is violating the manual.

Not only does the code disagree with the manual, but it’s also logically incorrect. With this code if you send a second i2c packet before the first packet has had time to generate the STOP condition this code won’t allow the STOP condition of the first packet to be generated.  In other words, this code incorrectly clears any pending STOP conditions of pervious packets. 

The code seems to work fine by eliminating all references to the I2C_I2CONCLR_STOC bit.

Additionally, in the header file the I2C_I2CONCLR_STOC define should be eliminated since the manual sezs there’s no such thing…


By the way, it doesn’t look like the git archive (http://git.lpcware.com//lpc175x_6x.git) has been updated in over any year.  Is this a link stale?

Cheers,
Jeff
Labels (1)
0 Kudos
0 Replies