Need help understanding writing to upper 32K on eeprom

Don M

I have programmed Kye's I2C Rom Demo. It allows you to read and write bytes, words & longs in the eeprom.

As I understand it the propeller uses the lower 32K of an AT512 eeprom during programming and bootup etc. So I am reading and writing to a location well above the 7FFF limit - 9000. I can write to the location, read the data that I wrote to the location, press reset on the board and even power down the board and power back and read the location ok. But if I reload the program the data is now gone from that location. Using Propeller Tool V1.3.

I thought that it wasn't supposed to touch anything above 7FFF?

Mike Green

It doesn't. Are you really sure you have a 64K EEPROM? It sounds like you have a 32K EEPROM. A 32K EEPROM ignores the 16th address bit, so the upper 32K looks like it's there, but it's really the lower 32K that you're accessing.

Don M

I am using the Prop proto boards. The eeprom says AT512 on it.

Don M

From the Propeller Proto Board product page: "64 KB EEPROM for program and data storage". How else can I confirm?

Don M

Mike Green wrote: »

It doesn't. Are you really sure you have a 64K EEPROM? It sounds like you have a 32K EEPROM. A 32K EEPROM ignores the 16th address bit, so the upper 32K looks like it's there, but it's really the lower 32K that you're accessing.

Mike- If that was the case wouldn't a dump of the memory at 8000 show the same contents as 0000? Everything above 8000 is all 0's unless I store something there. It stays until reprogrammed by the Prop Tool.

Mike Green

The Propeller Tool simply does not touch anything above $7FFF. An uninitialized portion of an EEPROM will all be $FF bytes until something is stored there. Perhaps there's something wrong with the memory dump program you're using. Try using DongleBasic from the ObEx. It has a memory dump statement for both RAM and EEPROM that's known to work properly. It will also let you read and write individual EEPROM locations and, again, is known to work properly. Look at the brief manual that comes with it.

Don M

Ok. I installed dongle basic. I figured out how to read locations- "dump $9000,16" for instance (I realized I needed to add the $ or it would read a decimal value of the address) but I don't see how to write to a location. Quick hint?

Don M

Here's the other program I was trying to use. Maybe you can try it?

Mike Green

To write to a location:

EEPROM[$9000] = 16

To display the contents of a location:

PRINT EEPROM[$9000]

The address can be any expression, so you could write a short loop to set all the bytes in an area to the same value or a calculated value
or you could write a loop that displays several locations in a row.

Mike Green

The DUMP statement, as you've written it, displays the contents of hub RAM or ROM. To display the contents of EEPROM, you need to write:

DUMP [$9000],16

Mike Green

The version of the I2C routines that you're using is buggy. I'd suggest you use this other one instead.

Phil Pilgrim (PhiPi)

Don M wrote:

I realized I needed to add the $ or it would read a decimal value of the address

Perhaps this has been the problem all along. If you write something to address 9000 in Spin, it will get written to address $2328, which is in the lower 32K of EEPROM. In Spin all hex literals have to be preceded by a dollar sign ($); otherwise, the number is interpreted as decimal.

-Phil

jeff-o

I've found, using Memory Storage Management, that the upper 32K is erased when loading a program to the EEPROM, but is left untouched when simply loading to ROM.

train nut

I have used BS2_I2C routines from OBX to store data to the upper 32k of a 24lc512 64k eeprom. The data has always been there no matter how many time I reload the program to EEPROM.

Phil Pilgrim (PhiPi)

jeff-o wrote:

I've found, using Memory Storage Management, that the upper 32K is erased when loading a program to the EEPROM, but is left untouched when simply loading to ROM [sic: RAM?].

That is simply not true, and I think you need to recheck your findings. My experience is exactly the opposite.

-Phil

Mike Green

jeff-o,
That doesn't make any sense. You can't load to ROM. The Propeller's bootloader, when it's copying RAM to EEPROM, stops at $8000 after copying $7FC0-$7FFF, so it's incapable of affecting the upper 32K of an EEPROM. The bootloader's source code is available, so you can look at it and verify this.

jeff-o

And yet, mine behaves differently. I've got two main programs; one that is loaded permanently and one that is only loaded into RAM. The one that loads into RAM is responsible for filling the upper 32k with strings, arrays and other stuff that won't fit in the main program. If I 'run' the memory loader program then load the main program permanently afterwards, all the data is gone. But if I load permanently first, then run the temp program, then start up the main program again, the data is there.

But you're right, I do need to figure out what the heck is going on, because it shouldn't be doing that.

localroger

Is your main program doing a sanity/init check that might be failing? I usually check for a recognition code somewhere whose absence means "need to initialize everything." A bug in that code could cause you to stomp legitimate data because the main program doesn't realize it's valid.

Don M

Mike- I tried your commands with Dongle Basic and yes it works after a complete reflash on my board. Thought I'd let you know.

Kye

@Don M - I just tired my code on a parallax proto board and it works fine. The functions take an argument of a decimal number... not a hex number. So, you were writing to low memory addresses the whole time.

As in the demo... "getl 32768" gets the first four bytes of the upper eeprom.

[You could have looked at the code and saved your self alot of time... the functions to read and write have alot of verbose function calls to "decimalToInteger" and "integerToDecimal"] - Guess its my fault for not being clearer.

Thanks,

Mike Green

For writing your program, either Basic_I2C_Driver from the ObEx or the low level I2C driver in FemtoBasic (sdspiFemto.spin) are straightforward to use. The comments in each file describe how to use them. Basic_I2C_Driver is easier to use.

Mike Green

Kye,
In the version that Don M posted, a number of routines use "result &=" in calling lower level routines. Since result is initialized to zero, this will never return the error result from the lower level routines since zero & anything always == zero. Also, in the lower level routines, it looks like the high order bit of the 16 bit address is not shifted properly before being masked off, so it's effectively ignored. That could explain why it looks like the upper 32K of the EEPROM is being erased.

Kye

I'm using this one. Everything works fine. The read functions aren't used to return an error.

The only complaint I get from this driver it that it expects a pull up resistor on the CLK and DAT lines (Per I2C spec). Never had a problem with anything else in it.

In the version that Don M posted, a number of routines use "result &=" in calling lower level routines. Since result is initialized to zero, this will never return the error result from the lower level routines since zero & anything always == zero. Also, in the lower level routines, it looks like the high order bit of the 16 bit address is not shifted properly before being masked off, so it's effectively ignored. That could explain why it looks like the upper 32K of the EEPROM is being erased.

My code is more clever than that Mike. Look again...

Mike Green

Kye,
I'm sorry. I mis-read your code. It does take more effort than I initially put in to really figure it out ( ... self-flagellation ... grovelling ... ah ooooh )

jeff-o

localroger wrote: »

Is your main program doing a sanity/init check that might be failing? I usually check for a recognition code somewhere whose absence means "need to initialize everything." A bug in that code could cause you to stomp legitimate data because the main program doesn't realize it's valid.

Nope, no sanity check; it just assumes it's there. If it's not there, it loads zeros. I first thought it was a 12blocks thing, so I tried everything using bst, with the same effect. I also thought that the program might like to have the memory storage object loaded a little later; so I moved the "init" code as late as possible. Again no success. The other issue I'm having is that the board no longer boots up from the eeprom from a cold start. It used to - before I added in the memory management code. And it still does; if I load a program that contains no memory management code. Memory storage starts at 8020, BTW.

The only thought I've got at this point is that I called some of my local variables the same thing as some of the storage locations in the upper 32k - perhaps they are interfering with each other somehow? I made them the same to make the code easier to understand. But enough of hijacking someone else's thread with my own - I'll start a new thread if I can't figure this out on my own.