Unable to access high side of 24lc512 on my PPD

tj4shee · 2015-01-20 16:49

Hi, was hoping someone could offer some suggestions or reasons on what I am doing wrong.....

I have a Parallax Prof. Dev. Board.. and I replaced the 24lc256 eeprom with a new 24lc512.... with the hopes of using the space at $8000 and above....

But I can't seem to get to it via the typical eeput routines.... the commands do nothing.... verified via Tachyon Forth and dumping the area I was trying to write to.

I know the chip is good... I can read and write to $8000 using Tachyon Forth..... and I am able to load and run programs from the bottom half of the chip.... i.e.... thats where I load and run Tachyon....

So any suggestions on what I fail to know or do ?

Thanks, TJ

Peter Jakacki · 2015-01-20 17:27

tj4shee wrote: »

Hi, was hoping someone could offer some suggestions or reasons on what I am doing wrong.....

I have a Parallax Prof. Dev. Board.. and I replaced the 24lc256 eeprom with a new 24lc512.... with the hopes of using the space at $8000 and above....

But I can't seem to get to it via the typical eeput routines.... the commands do nothing.... verified via Tachyon Forth and dumping the area I was trying to write to.

I know the chip is good... I can read and write to $8000 using Tachyon Forth..... and I am able to load and run programs from the bottom half of the chip.... i.e.... thats where I load and run Tachyon....

So any suggestions on what I fail to know or do ?

Thanks, TJ

So in TF you should be able to do EC!, EW!, and E! to write bytes, words, and longs. Then dump out the EEPROM to verify it has written.
$12345678 $F800 E! ok
$F800 $20 EE DUMP
0000_F800: 78 56 34 12 FF FF FF FF FF FF FF FF FF FF FF FF xV4.............
0000_F810: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................ ok

But this begs the question, what do you mean by "the typical eeput routine"? Isn't that something you should be elaborating on?

tj4shee · 2015-01-20 17:47

Peter Jakacki wrote: »

So in TF you should be able to do EC!, EW!, and E! to write bytes, words, and longs. Then dump out the EEPROM to verify it has written.
$12345678 $F800 E! ok
$F800 $20 EE DUMP
0000_F800: 78 56 34 12 FF FF FF FF FF FF FF FF FF FF FF FF xV4.............
0000_F810: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................ ok

correct....

Peter Jakacki wrote: »

But this begs the question, what do you mean by "the typical eeput routine"? Isn't that something you should be elaborating on?

sorry, didn't specify I was using SimpleIDE and C.... for which Simpletools.h has a set of commands to write to the eeprom..... so this code does not write to the eeprom....

/*
  EEPROM Data.c

  Write values and text to the Proepller Chip's dedicated EEPROM, and then
  read back and display.
  
  http://learn.parallax.com/propeller-c-tutorials
*/
#include "simpletext.h"
#include "simpletools.h"                      // Include simpletools header    .

int main(void)                                // main function
{
    ee_config(28, 29, 0);
    int addr = 32769;                           // Pick EEPROM base address. 

    ee_putInt(42, addr);                        // 42 -> EEPROM address 32769
    int eeVal = ee_getInt(addr);                // EEPROM address 32769 -> eeVal
    print("myVal = %d\n", eeVal);               // Display result

    ee_putStr("hello!\n", 8, addr + 4);         // hello!\n -> EEPROM 32773..32780
    char s[8];                                  // Character array to hold string
    ee_getStr(s, 8, addr + 4);                  // EEPROM 32773..32780 -> s[0]..s[7]
    print("s = %s", s);                         // Display s array
}

TJ

JonnyMac · 2015-01-20 17:49

The PPDB doesn't have a pull-up on the EEPROM SCLK line -- this may be causing the problem.

tj4shee · 2015-01-20 17:55

It seems to be hanging on any ee_put commands.... and the ee_get commands return nothing.. empty string...

tj4shee · 2015-01-20 17:56

JonnyMac wrote: »

The PPDB doesn't have a pull-up on the EEPROM SCLK line -- this may be causing the problem.

hmmmm.. ok.. going to try putting a resistor on it....

tj4shee · 2015-01-20 17:59

JonnyMac wrote: »

The PPDB doesn't have a pull-up on the EEPROM SCLK line -- this may be causing the problem.

That was definitely the problem.... me making assumptions....

THANKS ! Wish I would have asked on here before scratching my head for hours..... live and learn

Peter Jakacki · 2015-01-20 18:20

tj4shee wrote: »

That was definitely the problem.... me making assumptions....

THANKS ! Wish I would have asked on here before scratching my head for hours..... live and learn

I wonder why these other EE routines don't bother driving the clock high since it's a single master system and for all practical purposes there isn't a slave chip that I know or I have ever come across that tries to pull-down the clock line anyway, certainly not EEPROMs. This is a problem with reading "standards" too literally or comprehensively without applying balance as a lot of this stuff in the standard just doesn't apply. SMB is basically I2C but without all that overhead that is never needed in a single-master system.

The other thing is that the pull-up resistors that do get used are a bit light on in terms of pull-up anyway although fine for internal lower speed stuff could slew too slowly for high speed clocking and longer lines and more chips etc. Better off driving the clock push-pull rather than rely upon a pull-up.

BTW, your eeput tests should have revealed it didn't work for lower eeprom too but I guess you were too "focused" on high eeprom

As I always say, always be methodical and cross check and cross check the cross check etc.

tj4shee · 2015-01-20 18:30

Peter Jakacki wrote: »

I wonder why these other EE routines don't bother driving the clock high since it's a single master system and for all practical purposes there isn't a slave chip that I know or I have ever come across that tries to pull-down the clock line anyway, certainly not EEPROMs. This is a problem with reading "standards" too literally or comprehensively without applying balance as a lot of this stuff in the standard just doesn't apply. SMB is basically I2C but without all that overhead that is never needed in a single-master system.

The other thing is that the pull-up resistors that do get used are a bit light on in terms of pull-up anyway although fine for internal lower speed stuff could slew too slowly for high speed clocking and longer lines and more chips etc. Better off driving the clock push-pull rather than rely upon a pull-up.

BTW, your eeput tests should have revealed it didn't work for lower eeprom too but I guess you were too "focused" on high eeprom
As I always say, always be methodical and cross check and cross check the cross check etc.

Good points... I am going to see what happens if I remove the resistor and programmatically drive the SCL high before access...

TJ

Unable to access high side of 24lc512 on my PPD

Comments