Onboard I2C 24LC64 EEPROM on LPCXpresso1769

[lpcware]

Content originally posted in LPCWare by larryvc on Sun Mar 06 13:21:44 MST 2011
Has anybody written simple code to write/read the 24LC64 EEPROM and display results either to the console or UART?

I would prefer to not have to reinvent the wheel.:)

NXP we really need a method to post and share code on this forum.:cool:

[lpcware]

Content originally posted in LPCWare by dcika on Thu Mar 15 16:32:48 MST 2012
I just want to say thanks, your code for 24LC64 was just what I needed while porting some old stuff from the 8051/93C66 combination.

Regards,

Drazen

[lpcware]

Content originally posted in LPCWare by larryvc on Mon Mar 07 13:12:48 MST 2011
Just pinging.  I don't know if you saw my last post before your last reply.  We may have been posting at about the same time.:)

I am also thinking about writing an EEPROM library to handle byte writes, full and partial page writes with page increment, and random and sequential reads.  Also for I2C offboard devices. Feeling ambitious.

[lpcware]

Content originally posted in LPCWare by jharwood on Mon Mar 07 12:54:13 MST 2011
Yes, the original size was 6, I upped it to 32.  Please feel free to change it to 35.

[lpcware]

Content originally posted in LPCWare by larryvc on Mon Mar 07 12:39:46 MST 2011
jharwood and possibly Rob65

I looked into i2c.h and i2c.c and did confirm that only 29 data bytes could be written as currently BUFSIZE = 32.

I modified the code. Take a look and give me feedback.  main.c uses Semihosting.

[lpcware]

Content originally posted in LPCWare by larryvc on Mon Mar 07 10:33:18 MST 2011
Yes that is correct and I had an old datasheet.  Last night I tried to send more by increasing BUFSIZE and the data wrapped when it hit 32 bytes.  It was late and I didn't get a chance to post.  So we are stuck with max 32 byte writes.

Shouldn't BUFSIZE for I2CMasterBuffer[] be 35 so that 32 bytes, a full page of data, can be written?  1 Byte for Device address, 2 bytes for memory address, and 32 bytes for data.

Random and Sequential reads are supported across an entire device. If you have multiple devices cascaded you have to address the next device as sequential reads are not supported across device boundaries.

This is off subject but ESC is in Silicon Valley May 2-5 with Steve Wozniac as the keynote speaker.  I plan on attending.  Might be a good place to meet other forum members and maybe  NXP  reps.  I may start a new thread for this.

[lpcware]

Content originally posted in LPCWare by jharwood on Mon Mar 07 09:54:29 MST 2011

---

Quote: larryvc


To send more data than a page to the device do we update the data and the address and call I2CEngine() again?

---

Yes.

---

Quote:

In the Byte write section of the 24LC64 document it says "the internal address counter will point to the address location following the one that was just written".  Do you know if this counter allows writing across page boundaries i.e. sequential writes of more than 32 bytes?  It seems to imply this.

---

I think that statement only appears in the Random Read (8.2) section of the data sheet.

No more than 32 bytes can be written to the device in any one operation.

[lpcware]

Content originally posted in LPCWare by larryvc on Sun Mar 06 22:37:58 MST 2011
No problem. I thought mentioning it was a good idea.  I find that I often leave in testing code that sometimes takes hours to find and with embedded every byte counts.

The 24LC64 can do both byte and page writes.

Page writes on the device and BUFSIZE in the code are 32 bytes.  I know that we can't write beyond page boundaries.

To send more data than a page to the device do we update the data and the address and call I2CEngine() again?

In the Byte write section of the 24LC64 document it says "the internal address counter will point to the address location following the one that was just written".  Do you know if this counter allows writing across page boundaries i.e. sequential writes of more than 32 bytes?  It seems to imply this.

[lpcware]

Content originally posted in LPCWare by jharwood on Sun Mar 06 21:55:50 MST 2011
Ah yeah, sorry for the confusion. The original test did a write and immediate read back. So I added an extra test, i2ctest_rd(), to confirm the data after a power down. So i2ctest_wr() doesn't really need the read back part now.

[lpcware]

Content originally posted in LPCWare by larryvc on Sun Mar 06 20:58:49 MST 2011
Perfect.  Just what I was looking for and a great time saver. I had been fighting problems in other example code for some days now.

I just threw this together to test it:

 /*
===============================================================================
 Name        
: main.c
 Author      : 
$(author)
 Version     
:
 Copyright   : $(copyright)
 Description : main 
definition
===============================================================================
*/
 
 
#ifdef __USE_CMSIS
#include "LPC17xx.h"
#endif
 
 
#include <cr_section_macros.h>
#include <NXP/crp.h>
 
 
__CRP const unsigned int CRP_WORD = CRP_NO_CRP ;
 
 
#include <stdio.h>
#include "i2ctest.h"
#include "i2c.h"
 
 
int i;
 
 
int main(void) {
 
 i2ctest_wr();
 for (i = 0; i <= 7; i++) {
  printf("MasterBuffer[%d] = %X\n", i, I2CMasterBuffer);
 }
 
 
 printf("\n");
 
 
 i2ctest_rd();
 for (i = 0; i <= 7; i++) 
{
  printf("SlaveBuffer[%d] = %X\n", i, I2CSlaveBuffer);
 }
 
 while(1);
 return 0;
}

I was wondering where MasterBuffer[3] was being changed from 55 to A1 until i saw the extra call to I2CEngine() after /* Write SLA(W), address, SLA(R), and read 4 bytes back. */ section in i2ctest.c.  Commented that section out and got 55. Not a bug, just extra code?

Thanks jharwood and Rob65

[lpcware]

Content originally posted in LPCWare by jharwood on Sun Mar 06 16:58:32 MST 2011
Sure, Rob65 did a great job of cleaning up the I2C driver code and posted it in this thread:  http://knowledgebase.nxp.com/showpost.php?p=2773&postcount=11

I took Rob's code and ported it to the LPC1769 mcu and 24LC64 (which needs two byte addresses).