LPCXpresso IDE中的主题 Re: I2C on LPC1343

I2C on LPC1343

lpcware — Wed, 15 Jun 2016 21:57:50 GMT

Content originally posted in LPCWare by JohnBurton on Thu Jul 15 10:07:06 MST 2010
I'm trying to use the I2C on an LPC1343 LPCXpresso board to read and write an EEPROM chip.

I've taken the example code from the I2C sample and adapted it.
I've set the A0,1,2 pins on the chip to 0,and connected the SDA and SDC lines to the board with pullup resistors too.

The code I'm trying to use looks like this - but it never reads anything back. Most worryingly if I remove the chip entirely just keeping the pins with the pullups then it does exactly the same.

Is there anything else I have to do to make this work? I'm presuming I2CInit will set up the hardware settings required for this? Or am I missign something else I need to do?

Thanks for any suggestions


#define EEPROM_ADDR 0xA0

int main(void)
{
int f;
I2CInit(I2CMASTER);

// Write the byte 0xFD into location zero in the EEPROM
I2CWriteLength = 4;
I2CReadLength  = 0;
I2CMasterBuffer[0] = EEPROM_ADDR;
I2CMasterBuffer[1] = 0x00;// 2 byte address zero
I2CMasterBuffer[2] = 0x00;
I2CMasterBuffer[3] = 0xFD;
I2CEngine();

// And read it back, should appear at IC2MasterBuffer[3 + 2] ...?
I2CWriteLength = 3;
I2CReadLength  = 1;
I2CMasterBuffer[0] = EEPROM_ADDR;
I2CMasterBuffer[1] = 0x00;// 2 byte address zero
I2CMasterBuffer[2] = 0x00;
I2CMasterBuffer[3] = EEPROM_ADDR | RD_BIT;
I2CEngine();

return 0 ;
}

Re: I2C on LPC1343

lpcware — Wed, 15 Jun 2016 21:57:51 GMT

Content originally posted in LPCWare by Ex-Zero on Thu Jul 15 10:18:04 MST 2010
Did you scope SCL / SDA and what EEPROM ?

Re: I2C on LPC1343

lpcware — Wed, 15 Jun 2016 21:57:51 GMT

Content originally posted in LPCWare by Rob65 on Thu Jul 15 10:45:07 MST 2010
John,

a quick look at the sample code shows:

  /* Write SLA(W), address, SLA(R), and read one byte back. */
  I2CWriteLength = 2;
  I2CReadLength = 4;
  I2CMasterBuffer[0] = PCF8594_ADDR;
  I2CMasterBuffer[1] = 0x00;        /* address */
  I2CMasterBuffer[2] = PCF8594_ADDR | RD_BIT;
  I2CEngine();

It looks like the I2CReadLength needs to be 3 more than the number of bytes to be read. Seems like the I2CReadLength name is a bit misleading.

Rob

Re: I2C on LPC1343

lpcware — Wed, 15 Jun 2016 21:57:52 GMT

Content originally posted in LPCWare by JohnBurton on Thu Jul 15 11:13:11 MST 2010
Thank you for looking.
My problem turned out to be this paragraph in the example i2ctest.c

Quote:

(3) If it's a I2C Write/Read with repeated start, specify the
I2CWriteLength, fill the content of bytes to be written in
I2CMasterBuffer, specify the I2CReadLength, after the repeated
start and the device address with RD bit set, the content of the
reading will be filled in I2CMasterBuffer index at
I2CMasterBuffer[I2CWriteLength+2].

It does not fill in the I2CMasterBuffer at that location it fills in the result in I2CSlaveBuffer at the start. It appears that this comment is simply wrong. Perhaps the sample can be updated.

Re: I2C on LPC1343

lpcware — Wed, 15 Jun 2016 21:57:53 GMT

Content originally posted in LPCWare by Rob65 on Thu Jul 15 14:10:08 MST 2010
Ouch!

Quote: JohnBurton
It appears that this comment is simply wrong. Perhaps the sample can be updated.

I used to work at NXP and wrote these kind of sample programs (not for the LPCXpresso). Seeing these kind of errors just hurts :eek:

Good thing you found this bug - I'll be needing the I2C driver in a week or so myself.
Maybe some of the Xpresso users could join in creating a set of (tested) standard drivers. I have already noticed that other sample programs also have errors; the SPI sample gives a wrong frequency for the CPI clock - here also comment and code do not match ...

Rob

Re: I2C on LPC1343

lpcware — Wed, 15 Jun 2016 21:57:53 GMT

Content originally posted in LPCWare by JohnBurton on Sun Jul 18 03:49:53 MST 2010
I agree that some better tested documented library code would be a very good thing.

And samples are very good, but a library would be better :)

Re: I2C on LPC1343

lpcware — Wed, 15 Jun 2016 21:57:54 GMT

Content originally posted in LPCWare by ktownsend on Sun Jul 18 15:09:25 MST 2010

Quote: Rob65
It looks like the I2CReadLength needs to be 3 more than the number of bytes to be read. Seems like the I2CReadLength name is a bit misleading.

That definately had me scratching my head a bit as well when I was putting together some I2C drivers a while back. You indeed need to use one byte more than WriteLength would have you believe. For example (for an I2C eeprom):

 
  // Clear buffers
  for ( i = 0; i < I2C_BUFSIZE; i++ )
  {
    I2CMasterBuffer = 0x00;
    I2CSlaveBuffer = 0x00;
  }
  // Write address bits to enable random read
  I2CWriteLength = 3;
  I2CReadLength = bufferLength;
  I2CMasterBuffer[0] = MCP24AA_ADDR;                    // I2C device address
  I2CMasterBuffer[1] = ((address >> 8) & 0xFF);         // Address (high byte)
  I2CMasterBuffer[2] = (address & 0xFF);                // Address (low byte)
  // Append address w/read bit
  I2CMasterBuffer[3] = MCP24AA_ADDR | MCP24AA_READBIT;  
  // Transmit command
  i2cEngine();

It's not really complicated once you know the magic formula, but I can imagine a lot of people really wondering why their code isn't working if they didn't look carefully at the provided examples to notice that. That said ... the examples still saved me a lot of time compared to starting with just the user manual in hand, so I don't want to complain TOO loudly either.

Re: I2C on LPC1343

lpcware — Wed, 15 Jun 2016 21:57:54 GMT

Content originally posted in LPCWare by JohnBurton on Sun Jul 18 15:21:24 MST 2010
Yes, ReadLength needs to be the actual number of bytes you want to read.

WriteLength is the number of bytes to send including the address. But if you want to read any bytes then you have to send the address again with the R/W bit set but don't include this in the write length.

The interface to this functionality isn't great, it would be much better to have separate I2C_Read and I2C_Write commands that take pointers to read and write buffers and their ACTUAL sizes. Shouldn't be too hard to wrap or rewrite to do this.

Re: I2C on LPC1343

lpcware — Wed, 15 Jun 2016 21:57:55 GMT

Content originally posted in LPCWare by Rob65 on Mon Jul 19 04:01:30 MST 2010
and a user manual that is complete and correct would also be useful ...

In both the lpc11xx and the 13xx user manuals there is no proper reference to the I2C_PCLK clock. In the clocking and power control chapter (10.7 for the 11xx, 12.7 for the lpc13xx) there is a PCLK_I2C clock mentioned.
Later on there are mixed references to PCLK_I2C and I2C_PCLK used in the register description for the duty cycle registers and a table lists different duty cycle values for different PCLK_I2C values but besides these references to this clock there is no description of what its value is or how to set this value.

In the lpc11xx sample 0x180 is used for the duty cycle registers and this results in a ~62.11 kHz I2C clock - what has the guy programming this been thinking ???

Looks like the PCLK is about 48 MHz. With the 48 MHz I did some calculations:

[LIST=1]
[*]400 kHz should use I2CSCLH+I2CSCLL of 120
the actual frequency is 384 kHz (2.6 us clockcycle instead of 2.5 us)
[*]100 kHz should use I2SCLH+I2SCLL of 480
the actual frequency is 99 kHz (10.1 us cycle instead of 10 us)
[*]the 0x180 values (totals up to 768) should result in 62.5 kHz
actual cycle is 16.1 us instead of the calculated 16 us
[/LIST]
Fun isn't it? There is actual always a 0.1 us different in the calculated and the real clock cycle values :eek:
For 100 kHz I2CSCLH + I2CSCLL should be 475 (I used 237 for SCLH and 238 for SCLL) and 400 kHz needs a total of 115 (58 + 57) - this is tested on an lpc11xx Xpresso module from EA using a logic analyzer with a 200 MHz sampling rate.

Dear NXP, please enlighten us about the I2C_PCLK and how to calculate the SCLH/SCLL values. Where does this 0.1 us difference between the suggested calculation in the user manual an (my) real world come from?

Rob

Re: I2C on LPC1343

lpcware — Wed, 15 Jun 2016 21:57:55 GMT

Content originally posted in LPCWare by Rob65 on Mon Jul 19 08:40:16 MST 2010
I am just now digging through the code.
This indeed is (just) sample code and not suited for real life apps.

Comments do not always match with the code - E.g: the init function says it returns FALSE if the interrupt handler was not installed while in fact always a TRUE is returned and there is no check to see if the interrupt routine is installed (this is done at link time) ...

There are a number of while(1) loops, I don't think this is good coding.
E.g:

  while( 1 )
  {
    if ( I2CMasterState == I2C_STARTED )
    {
      retVal = TRUE;
      break;    
    }
    if ( timeout >= MAX_TIMEOUT )
    {
      retVal = FALSE;
      break;
    }
    timeout++;
  }
  return( retVal );

I think that:

 while((I2CMasterState != I2C_STARTED) && (timeout < MAX_TIMEOUT))
      timeout++;
  return (timeout >= MAX_TIMEOUT);

is more readable

and what about the I2CEngine function. This contains:

  while ( 1 )
  {
    if ( I2CMasterState == DATA_NACK )
    {
      I2CStop();
      break;
    }
  }

I got the creeps from reading this.
Why do we wait forever and only stop on a DATA_NACK state ???
In the end I figured out that the DATA_NACK state is an internal state used by the interrupt state machine and the DATA_NACK is misused for the perfectly legal (and acknowledged by the slave) ending of the transaction.
The interrupt routine already sent out the STOP condition so there is no need to do this again ...
And the state machine does not even check for an ACK or NACK after sending a byte ...

But then, this code is usable as an example to write my own driver but I would not call this a good example.

Looking at John's original code, this I2C driver will not suffice for an EEPROM like the 24LC08 - after writing the data, you need to do something called "Acknowledge polling": The 24LC08 keeps retuning a NACK on the slave address+R/W=0 as long as it is writing to memory so before reading valid data we need to make sure we received an ACK on the slave address.

I hope to change the code and test it today. I will post my code when finished.

Rob

Re: I2C on LPC1343

lpcware — Wed, 15 Jun 2016 21:57:56 GMT

Content originally posted in LPCWare by Rob65 on Mon Jul 19 13:27:56 MST 2010
Done!
The attachment contains the updated driver as an exported Code Red project.
Note that I did this on an LPC1114 module, you need to change the references to the LPC11xx.h header file for an lpc13xx.

I changed the state machine in the interrupt:

[LIST]
[*]Added some comment to clarify the different states
[*]removed the assignments to I2CMasterState (these were not used).
[*]Changed I2CMasterState to give the result of the transaction
[*]fixed a bug (on a read there was actually one byte more read than requested).
[*]Added consequent handling for sending a STOP condition removing the need to send a STOP condition from I2CEngine()
[/LIST]
I also added a timeout to I2CStop() and the I2CEngine now returns a transaction result.

The i2ctest.c is almost the same, all I did was a small change to use a 24LC08 EEPROM as a device and I added a check on the EEPROM read.
The 24LC08 will return a NACK on the slave address as long as it is writing the data to EEPROM. When this happens the I2CEngine will return the I2CSTATE_SLA_NACK value and the test program will loop until an actual read has taken place.

There is also a screendump from the logic analyzer available showing all transactions but that image is too large for this forum. The image is available at: http://myvoice.nl/software/#XpressoDrivers

If there still is anything wrong with this driver feel free to shoot me (ehh... drop me an email) and I'll try to fix it.

Some notes:

[LIST]
[*]no real documentation added
[*]no extensive testing on fault conditions, the states 0x30, 0x38 and 0x48 in the state machine have not been tested
[*]I did not check all existing comments, there may still be some faulty comments
[*]the I2C clock is set to 400 kHz on the lpc1114, besides editing the i2c.h file there is no means to change the clock frequency.
[/LIST]
Regards,

Rob

Re: I2C on LPC1343

lpcware — Wed, 15 Jun 2016 21:57:57 GMT

Content originally posted in LPCWare by waterforces on Tue Jul 20 01:56:05 MST 2010
I like function like :writeI2C(...) and readI2C(...), why use I2CEngine()? It makes me confused that perparing I2CMasterBuffer!

Re: I2C on LPC1343

lpcware — Wed, 15 Jun 2016 21:57:57 GMT

Content originally posted in LPCWare by Rob65 on Tue Jul 20 03:31:52 MST 2010

Quote: waterforces
I like function like :writeI2C(...) and readI2C(...), why use I2CEngine()? It makes me confused that perparing I2CMasterBuffer!

I can understand this, yesterday's goal was just to get the example working, stable and a bit more readable. I am just now splitting the example into a separate (application) project and a static library for the i2c driver. Now I do see that I2CMasterBuffer and I2CSlaveBuffer are very confusing; these should be I2CWriteBuffer and I2CReadBuffer or even better have them as pointers to a buffer that is defined in the application (I need an 18 byte buffer for my EEPROM).

Having separate writeI2C() and readI2C() function may seem logical but in order to do a read you always have to do a write first, followed by a restart and then a read.
What the write needs to do depends on the actual device. My small EEPROM needs just 1 byte as memory address, the larger EEPROM needs 2 bytes.
And this write, restart, read is handled as one transaction by the interrupt routine. Therefore from a I2C perspective the I2CEngine() does make some sense.

What if I change the interface to the I2CEngine() a bit:
uint32_t I2CEngine( uint32_t BytesToWrite, uint8_t &WriteBuffer, uint32_t BytesToRead, uint8_t *ReadBuffer);
This as least makes a bit more sense than the fixed Master/Slave buffers we now have.

At the same time I'll also add a run-time configurable I2C clock.

Rob

Re: I2C on LPC1343

lpcware — Wed, 15 Jun 2016 21:57:58 GMT

Content originally posted in LPCWare by Lithium on Thu Oct 07 07:15:51 MST 2010
This topic is not that old,

I am also trying to get the I2C working, i am using an lpc1343 board.
I have found this topic and changed the example code to this code. I can understand about 90% of the code.

I need to read and write to an DS1307 real time clock ic.
On page 12 you can see how the data needs to be send: http://datasheets.maxim-ic.com/en/ds/DS1307.pdf

You need to send 3 times a byte, table 2 has only 2 bytes, one for the address and one for the data.
What about the 3th one?

To send data i need this:

  I2CWriteLength = 3;
  I2CReadLength = 0;
  I2CMasterBuffer[0] = MC24LC08_ADDR;
  I2CMasterBuffer[1] = 0x00;        /* address */
  I2CMasterBuffer[2] = 0x55;        /* Data0 */
  I2CEngine();

Is that correct? Buffer 0 for the address of the DS1307, buffer1 for the internal address and buffer2 for the data?
Where does the I2CEngine() put the data in that has been read?

Hope you can help me with those questions.

Edit:
The address of the DS1307 is: 1101000 followed by the direction bit (R/W), which for a write is 0 So that will be: 11010000 to write and 11010001 to read?
If i want this to put it into a hex value it will be D0 to write and D1 to read?

Re: I2C on LPC1343

lpcware — Wed, 15 Jun 2016 21:57:59 GMT

Content originally posted in LPCWare by Ex-Zero on Thu Oct 07 14:42:59 MST 2010
I've used DS1307Z with several AT90CAN's and can confirm that your reading and writing address is OK:

Quote:
[B][COLOR=#9d0000]#define DS_R 0xD1 //read = DS1307 ADDRESS +1 [/COLOR][/B]
[B][COLOR=#9d0000]#define DS_W 0xD0 //write= DS1307 ADDRESS +0[/COLOR][/B]

Although I didn't test this sample, it seems to work:

Writing data:
I2CMasterBuffer must be filled with DS_W, address, data
I2CWriteLength = 3;
I2CReadLength = 0;

Reading data:
I2CMasterBuffer must be filled with DS_R, address
I2CWriteLength = 2;
I2CReadLength = 1;

After starting I2CEngine(), everything should be done in I2C_IRQHandler().
Read data are stored in I2CSlaveBuffer.

Note: DS1307 min supply voltage is 4.5V, so I would suggest to use DS1338-33 (3.3V).

HTH,
Zero

Re: I2C on LPC1343

lpcware — Wed, 15 Jun 2016 21:57:59 GMT

Content originally posted in LPCWare by Mike45 on Thu Nov 04 07:39:47 MST 2010
good thread, i am going to try some i2c stuff today. What values should be used for a pullup?

Re: I2C on LPC1343

lpcware — Wed, 15 Jun 2016 21:58:00 GMT

Content originally posted in LPCWare by Ex-Zero on Thu Nov 04 07:49:19 MST 2010
I'm using 10k :) without problems. But everything between 1k and 10k should work.

How to calculate the correct value you can read in Chapter 17.2 of 'I2C-BUS SPECIFICATION'
[FONT=GillSans,Bold][SIZE=4]
[/SIZE][/FONT]http://www.nxp.com/acrobat_download2/literature/9398/39340011.pdf

Although the result of this calculation is about 1kOhm, a lot of circuits use a lower termination (=higher resistor). In practice EEPROMs with 400kHz and short I2C lines don't need high termination.
If you use higher speed and longer I2C lines (like I2C-Temperature sensor) it's a good idea to use higher termination (=lower resistance).

Re: I2C on LPC1343

lpcware — Wed, 15 Jun 2016 21:58:00 GMT

Content originally posted in LPCWare by Mike45 on Thu Nov 04 09:09:34 MST 2010

Quote: Zero
I'm using 10k :) without problems. But everything between 1k and 10k should work.

How to calculate the correct value you can read in Chapter 17.2 of 'I2C-BUS SPECIFICATION'
[FONT=GillSans,Bold][SIZE=4]
[/SIZE][/FONT]http://www.nxp.com/acrobat_download2/literature/9398/39340011.pdf

Although the result of this calculation is about 1kOhm, a lot of circuits use a lower termination (=higher resistor). In practice EEPROMs with 400kHz and short I2C lines don't need high termination.
If you use higher speed and longer I2C lines (like I2C-Temperature sensor) it's a good idea to use higher termination (=lower resistance).

ty ty:D

Re: I2C on LPC1343

lpcware — Wed, 15 Jun 2016 21:58:01 GMT

Content originally posted in LPCWare by ktownsend on Sat Dec 18 12:51:51 MST 2010
Rob65:

Just wanted to say thanks for taking the time to post an update. I was using the original i2c code and noticed the reads from EEPROM were randomly nutty. Digging into it, it turned out to be the generic i2c code. I'd been meaning to replace it since day one, but it was always lower on the todo list since it 'seemed' to work.

Kevin

Re: I2C on LPC1343

lpcware — Wed, 15 Jun 2016 21:58:02 GMT

Content originally posted in LPCWare by zzz on Fri Jan 07 00:46:08 MST 2011
Hi Guys,
Thanks Rob for updating the example. However I am having difficulty connecting to the PCF8574 I2C I/O Expander IC. Has anyone had any luck connecting to this device?
I modified the code for 100khz speeds.

#define I2SCLH_SCLH237  /* I2C SCL Duty Cycle High Reg */
#define I2SCLL_SCLL238  /* I2C SCL Duty Cycle Low Reg */

I set the correct address, commented out the read portion since i just have 8 LEDs connected to the I/O pins.
When I debug it never leaves I2CEngine() function:

  while (I2CMasterState < 0x100);
  return ( I2CMasterState );

Jon