Proto Board EEPROM

rapscaLLion · 2007-05-01 05:56

Hi,

I have transferred my working prototype from the demo board to the proto board.
Everything is working fine except the EEPROM, which does not seem to be writing
(or reading, could be either or both) from the given code. Upon closer inspection it
appears that the protoboard has a different EEPROM IC (AT512). I can't tell what
EEPROM the demo board is using, but it is not the same. What could possibly cause
the proto board EEPROM to not react in the same manner as the demo board?

Thanks,

Alex

Paul Baker · 2007-05-01 06:22

The difference between the Demo Board EEPROM and the Proto Board EEPROM is that the Demo Board has 32kB while the Proto Board has 64kB. Besides this difference they operate the same (otherwise the Proto Board wouldn't work at all). You haven't provided enough information about what you are doing to diagnose the issue (does it program and indicate a verified contents when you hit F11, etc).

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer

Parallax, Inc.

rapscaLLion · 2007-05-01 07:20

Hi,

The program loads to the EEPROM and verifies correctly. The program uses the minimal I2C code to access the EEPROM.

First, the program initializes its respective cogs. Second, it initializes the EEPROM like so:

' Initialize EEPROM
outa[noparse][[/noparse]28] := 1 ' set SCL high
dira[noparse][[/noparse]28] := 1
dira[noparse][[/noparse]29] := 0 ' set SDA as input
repeat 9 ' up to 9 cycles
outa[noparse][[/noparse]28] := 0 ' put out a clock pulse
outa[noparse][[/noparse]28] := 1
if ina[noparse][[/noparse]29] ' if SDA is not high, repeat
quit

It then checks the EEPROM at address $6FFE for a value greater than zero, which indicates that the appropriate values have previously been written.
If the value is zero it writes the defaults and sets $6FFE to 255. If the value is not zero, the program reads all the respective values to RAM. During the
program's operation, some EEPROM values might be written to based on user input.

On the demo board this all works fine, on the proto board the program initializes, finds a zero value at $6FFE and writes the defaults.

The minimal I2C library is accessed via the following functions (from the forums):

pub ewrite(reg,wcount)
ee.i2cWritepage(28,$A0,reg,@buffer,wcount)
waitcnt(clkfreq / 200 + cnt)
ee.i2cWriteWait(28, $A0, $7000)
pub ewritel(reg,wcount)
ee.i2cWritepage(28,$A0,reg,@lbuffer,wcount)
waitcnt(clkfreq / 200 + cnt)
ee.i2cWriteWait(28, $A0, $7000)
pub eread(reg,rcount)
ee.i2cReadPage(28, $A0, reg, @rbuffer, rcount)
waitcnt(clkfreq / 200 + cnt)
pub ereadl(reg,rcount)
ee.i2cReadPage(28, $A0, reg, @lrbuffer, rcount)
waitcnt(clkfreq / 200 + cnt)

Anything else I can tell you that may help?

Thanks

Post Edited (rapscaLLion) : 5/1/2007 3:32:52 PM GMT

Mike Green · 2007-05-01 13:26

The I2C routines have been tested on the Demo board, Protoboard, and Hydra and work fine on all three with their different EEPROMs.

In what you've posted, there are some obvious mistakes:

1) You don't need to use the WAITCNT if you call i2cWriteWait and you don't need the WAITCNT at all after read operations

2) The i2cWriteWait has to use the same address as the i2cWritePage, not a fixed address like $7000. In your code, change it to "reg".

3) Make sure that the block that's written (address / count) doesn't span a page boundary. This is discussed in the comments in the I2C library.

rapscaLLion · 2007-05-01 15:30

Thanks for all the help guys. Mike, I have followed the advice you have given and made all the changes.
In response to point number three, I write no more than one long at any given time, so it shouldn't be a
problem, unless there's something I'm not understanding. Alas, the EEPROM is still not working. I can't
tell if it is reading properly because nothing that I write to it actually gets written.

Any ideas? There's not much more for me to say, unless there's anything specific you want to know.

Thanks!

Mike Green · 2007-05-01 16:08

You can check whether you can read the EEPROM by using i2cReadPage to read from the first 4 bytes of the EEPROM into a long and compare it to the first 4 bytes of RAM using LONG[noparse][[/noparse] 0 ]. These should be the same (they're the value of _clkfreq).

The page wraparound shouldn't be a problem as long as you're writing LONGs to addresses that are a multiple of 4.

I wasn't quite correct on #2 (sorry). As the comments in the I2C routines show, you need to repeated call i2cWriteWait until it succeeds (and you should check i2cReadPage and i2cWritePage for errors) like:

PRI readIt
  if i2c.ReadPage(i2c#BootPin, i2c#EEPROM, eepromAddress, @buffer, 32)
    abort ' an error occurred during the read

PRI writeIt | startTime
  if i2c.WritePage(i2c#BootPin, i2c#EEPROM, eepromAddress, @buffer, 32)
    abort ' an error occured during the write
  startTime := cnt ' prepare to check for a timeout
  repeat while i2c.WriteWait(i2c#BootPin, i2c#EEPROM, eepromAddress)
    if cnt - startTime > clkfreq / 10
      abort ' waited more than a 1/10 second for the write to finish

If you have some kind of display on your device, you can display an error message rather than just doing an abort.

Proto Board EEPROM

Comments