Memory Management prevents Propeller from self-booting

jeff-o

So here's something strange. It would seem that when I use the Memory Management object, the propeller is no longer able to boot up by itself. Not only that, but any project that contains it seems to erase the entire EEPROM - even data stored in the upper 32k! Note that this is using a custom made board, though the connections to memory (including pull-up resistors) are identical to that of a standard propeller demo board. I did a quick experiment:

1. load a known working program to EEPROM
2. power down the propeller board, and turn on power with the prop plug removed
3. confirm the program boots OK
4. Drop the code to initialize Memory Management into my known working program (don't even bother reading or writing anything)
5. load the new program into EEPROM
6. power down the prop board, turn on with prop plug removed
7. board does NOT boot up

A second experiment involved writing data to upper 32k, permanently loading the "known working" program below, then watching all that data disappear.

I've got no explanation for it. My memory storage location starts at 8020, so it should be free and clear of the lower 32k.

The program below does nothing but blink two LEDs, using routines included with 12blocks. I've included both the 12b file and spin, as well as the memory storage object I've marked up with xml for 12blocks. My project is dead in the water if it can't boot by itself, so any help is much appreciated!

known working.zip

jeff-o

So far I've determined that I may have been misusing the "init" PUB. Should it be called at the beginning of the program no matter what? Is the "reset_all" somehow erasing all my data because it can't find entries in the table, even though there should be some?

Toby Seckshund

It's not one of those 8020 vs $8020 moments, is it?

Mike Green

"reset_all" is the routine that actually initializes the area from $8000 to $FFFF, so it makes sense that it might erase the first 32K if you happen to have a 32K EEPROM or if there's something wrong with the 64K EEPROM so it functions like a 32K EEPROM. I don't see anything obviously wrong with the "Memory Management" code and it's been around for a long time, so I doubt that there's something fundamentally wrong with it.

jeff-o

Don't think so; $8020 is definitely what is defined in the Constants (CON).

jeff-o

I've got a 128K device in there - would that make a difference? Would the code need tweaking to be compatible with a 128K device?

Edit: The device is a Microchip 24FC1026

Mike Green

I think all of the 128K devices provide two 64K blocks. There are different ways to select the 2nd 64K block depending on the manufacturer and part number, but all provide the 1st 64K block the same way as 64K devices.

jeff-o

Same manufacturer and same product line as the 64K device in the demo board, so you'd think they would work the same. I did see a mention of 128k page size support, would that make a difference?

Phil Pilgrim (PhiPi)

They can't possibly work the same -- at least not with a contiguous address space. This is due to the number of bits in a 128K address (17) and the number of address bits available in the I2C protocol (16). To overcome this, a 128K device has to be addressed as if it were two 64K devices at different physically-strapped device addresses. To accomplish this, in some 128K devices the A0 pin is made a no-connect and is assigned internally to distinguish between the two 64K blocks.

As Mike points out, addressing the lower 64K of a 128K EEPROM should be no different than addressing a 64K EEPROM. Accessing the upper 64K may be manufacturer-dependent.

-Phil

jeff-o

Thanks for your comments.

I have another project (The Plant Whisperer) in which I do much the same thing as I am attempting here, and it works fine. That's using a 64K chip from Atmel, and I'm using Memory Storage Lightweight for that one. At this point it would seem that the problem is either the chip itself, or something I accidentally messed up in the memory storage code. I can play around with Lightweight to see if it works better with this chip. If it doesn't, then perhaps this 128K device just isn't compatible with the memory storage object.

jeff-o

More experiments.

I rigged up Memory Storage Lightweight, and my experiences were the same. Loading a program onto the EEPROM still erases all the data stored on it (or at least the table...) and it is not able to boot up on its own. Since the Lightweight object I used here is an exact duplicate of the one I successfully used on the Plant Whisperer, I'm gonna have to say that this 128K EEPROM I used just isn't compatible for some reason. I'll see if I can pop in the 64K device I used on the Plant Whisperer (hmmm, I wonder if I have any left over?)

jstjohnz

The Atmel part, AT24C1024B, works properly with the existing driver (basic_i2c_driver) to access the full 128k bytes.

kuroneko

jeff-o wrote: »

At this point it would seem that the problem is either the chip itself, or something I accidentally messed up in the memory storage code.

FWIW, I just tried the known working project on my Hydra (adding the I2C driver and replacing the main loop which now simply flashes LED 5 and 6). Works as advertised. Second time around (after reset) it spots that it's been there before and calls get_name_list instead of reset_all. Regardless, the main loop is reached and just works.

jeff-o

kuroneko wrote: »

FWIW, I just tried the known working project on my Hydra (adding the I2C driver and replacing the main loop which now simply flashes LED 5 and 6). Works as advertised. Second time around (after reset) it spots that it's been there before and calls get_name_list instead of reset_all. Regardless, the main loop is reached and just works.

Thanks! That pretty much confirms to me that it's a hardware problem. I'll order a new 64K EEPROM tonight.

jeff-o

I checked the data sheet for the 128K EEPROM I used, and it would appear that it's expecting a 24 bit address (where the first five bits are ignored). In general, the waveforms are different enough that I'm surprised it was working at all...

Phil Pilgrim (PhiPi)

The device you've cited (24FC1026) uses a standard access protocol (1 bit block select and 16 bits address -- not sure where you get the 24 bit address stuff). On the contrary, I'm surprised it does not work in your application.

-Phil

jeff-o

Argh, I was looking at the 25xx1026 data sheet. You're right, the 24xx1026 does work the same. Apparently. I'm still going to replace the chip to see what happens...

Bobb Fwed

I state in the documentation that the object is only compatible with EEPROMs up to 64KB. Now I see, it is less compatible than I would have imagined (I never tested it, but the memory constraints in the object only allow 16 bit addresses).

The erasing/non-booting problem probably has to do with some incompatibility with the Basic I2C Driver with >64KB EEPROMs. The init and/or reset_all only erases information starting at store_info and before start_data (both values set in the CON).

jeff-o

Bobb Fwed wrote: »

I state in the documentation that the object is only compatible with EEPROMs up to 64KB. Now I see, it is less compatible than I would have imagined (I never tested it, but the memory constraints in the object only allow 16 bit addresses).

The erasing/non-booting problem probably has to do with some incompatibility with the Basic I2C Driver with >64KB EEPROMs. The init and/or reset_all only erases information starting at store_info and before start_data (both values set in the CON).

Heh, serves me right for being greedy and wanting all that storage space. I've got 64K parts on the way, so I will be able to confirm that it is a hardware issue by tomorrow night.

jeff-o

SOLVED!!!

It was indeed the EEPROM. I just installed a new 64K device (AT24C512BN) and it works flawlessly. And there you have it: DO NOT use the Microchip 128K EEPROM with Memory Storage, because it won't work!

Thanks for all your help and patience. Your knowledge and experience is, as always, much appreciated!