Shop OBEX P1 Docs P2 Docs Learn Events
512K EEPROM Substitute for 256K EEPROM — Parallax Forums

512K EEPROM Substitute for 256K EEPROM

Vega256Vega256 Posts: 197
edited 2011-02-08 22:02 in Propeller 1
Hey Guys,

I am preparing to order a Propeller MCU and I would like to store applications using external EEPROM. The schematics in the datasheet calls for a 24LC256 Serial EEPROM. Will a 24LC512 work in its stead?

Comments

  • SapiehaSapieha Posts: 2,964
    edited 2011-01-16 18:00
    Hi Vega256

    Without any problem --- Even 1024K

    Vega256 wrote: »
    Hey Guys,

    I am preparing to order a Propeller MCU and I would like to store applications using external EEPROM. The schematics in the datasheet calls for a 24LC256 Serial EEPROM. Will a 24LC512 work in its stead?
  • Duane DegnDuane Degn Posts: 10,588
    edited 2011-01-16 18:03
    Vega256,

    Yes, The Propeller Proto Board and others use a 512K EEPROM.

    Hey, Post 1. Welcome to the forum. It's lots of fun here. I hope you like the Prop. It's changed my life for the better.

    Let us know if you have any problems.

    Duane

    Edit: Sapieha, you type too fast!
  • Kal_ZakkathKal_Zakkath Posts: 72
    edited 2011-01-16 18:35
    Just to add a bit more info - in many cases people put 512k EEPROMs on so that the lower 32KB can hold a bootloader (for example, to load new firmware off an SD card) and the upper 32KB holds the program.

    usually it works like so:
    -prop starts up, loads the bootloader
    -bootloader checks SD for new version
    -if new version found, write it to upper 32K of EEPROM
    -load upper 32K of EEPROM
    -run program

    It makes it very easy to do in-the-field updates with just an SD card.
  • Vega256Vega256 Posts: 197
    edited 2011-01-16 18:41
    Thanks guys for the quick replies and the welcome.
  • agsags Posts: 386
    edited 2011-02-02 22:35
    Kal_Zakkath wrote: »
    -load upper 32K of EEPROM
    -run program.

    Sorry if I'm being dense here, but I'm searching for a way to accomplish my goal: I want to be able to download new code (using the Spinneret) over a LAN and boot the Prop from that. I've seen code that can do this, but it requires the bootloader to be part of the new code being downloaded.

    I can see how to boot from the lower 32k EEPROM, and that could be the bootloader. That bootloader can wait for an instruction (over the LAN) to boot from the upper 32k EEPROM or wait for a new program to be loaded (through the bootloader's HTTP capability) into upper 32k EEPROM, then loaded and run...

    I can't get my head around how to preserve the bootloader code in lower 32k EEPROM, while "loading" upper 32k EEPROM into the Propeller and then executing. If a "reboot" instruction is issued to the Propeller, it will automatically reload from lower 32k of EEPROM - which would be the bootloader in my case.

    If the bootloader lived in COG RAM (512x32bit) memory, I can maybe see how to do this. It's not obvious to me that I can write code to listen to a LAN connection through a WizNet5100 and fit it into that memory footprint.

    Any suggestions?

    Thanks.
  • Mike GreenMike Green Posts: 23,101
    edited 2011-02-02 22:44
    There are a number of ways to do this. The Spinneret's predecessor, the YBox2, used some of these ideas.

    You can keep the "bootloader" in the 1st 32K unchanged and always download a new program to the 2nd 32K. The "bootloader", when a reboot occurs, does some kind of checking of the 2nd 32K for validity. If valid, it loads the 2nd 32K into RAM and executes it (on top of itself since the hardware bootloader loads from the 1st 32K into RAM for execution). There's a special command for the "bootloader" that checks the 2nd 32K for some other kind of validity and copies the 2nd 32K of EEPROM on top of the 1st 32K of EEPROM so we have a new "bootloader" for next time.

    The Propeller Backpack does a variation on this where it has a small "bootloader" that sits in the lower end of EEPROM. The rest of the 1st 32K and a small portion of the 2nd 32K is used for any downloaded program. The rest of the 2nd 32K is available for data storage.
  • agsags Posts: 386
    edited 2011-02-02 23:03
    Mike Green wrote: »
    There are a number of ways to do this. The Spinneret's predecessor, the YBox2, used some of these ideas.

    You can keep the "bootloader" in the 1st 32K unchanged and always download a new program to the 2nd 32K. The "bootloader", when a reboot occurs, does some kind of checking of the 2nd 32K for validity. If valid, it loads the 2nd 32K into RAM and executes it (on top of itself since the hardware bootloader loads from the 1st 32K into RAM for execution). There's a special command for the "bootloader" that checks the 2nd 32K for some other kind of validity and copies the 2nd 32K of EEPROM on top of the 1st 32K of EEPROM so we have a new "bootloader" for next time.

    The Propeller Backpack does a variation on this where it has a small "bootloader" that sits in the lower end of EEPROM. The rest of the 1st 32K and a small portion of the 2nd 32K is used for any downloaded program. The rest of the 2nd 32K is available for data storage.

    Sorry, this is where I must be dense. If the bootloader copies the 2nd 32K EEPROM into the 1st 32K EEPROM, then hasn't it obliterated itself forever? If the 2nd 32K EEPROM wasn't loaded with bootloader code then it's back to the Prop Plug...

    Also, how do I "load the 2nd 32K EEPROM into RAM and execute it? If the bootloader is executing, it's in RAM (or COG RAM if PASM). Other than a "reboot" instruction, how do I load and execute instructions in HUB RAM while I'm executing? I must be missing something, and if appreciate any hints on this.
  • Nick McClickNick McClick Posts: 1,003
    edited 2011-02-02 23:17
    Bootloader copies 2nd 32k EEPROM into the hub, overwriting the contents of the hub. It can do this because it's running from a cog, which has its own RAM.

    No instructions ever execute from the hub - execution only occurs within the cogs. The bootloader gives a cog 512 instructions (running from cog ram) to read the upper 32k of eeprom and copy it to the hub.
  • agsags Posts: 386
    edited 2011-02-02 23:26
    I'm just dense here. If the bootloader is executing, it's either SPIN (bytecode resident in RAM, interpreted by a cog running the interpreter loaded from ROM) or PASM (running fully in cog RAM). So you're saying that I have to have the bootloader written in PASM, executing in a cog, and it then copies the 2nd 32K EEPROM to hub RAM? Once that happens, how do I get the Propeller to read RAM & execute from another cog without a reboot?
  • Nick McClickNick McClick Posts: 1,003
    edited 2011-02-02 23:34
    You got it. The final thing is 'COGNEW' and 'COGSTOP'. You're not rebooting the Propeller, you're just starting a cog on the new program in the hub and turning the original bootloader cog off. Mike knows the details much better than I, but that's how I conceptualize it.
  • agsags Posts: 386
    edited 2011-02-04 07:40
    OK, I'm getting my head around this, finally. A big key was realizing that the entire bootloader (meaning all operations I want to support in the "1st stage" program that loads upon bootup) functionality doesn't need to be written (& executed) in PASM; just the final step that actually copies a SPIN binary image from somewhere (SD card, EEPROM, etc.) into hub RAM needs to be PASM code. Great.

    Correct me if I'm wrong, but the last step is then to launch a new cog that will run the newly-loaded SPIN image in hub RAM. I found this in the Propeller Manual v1.1, page 285:
    It is not practical to launch Spin code from a user’s Propeller Assembly code; we recommend launching only assembly code with this instruction.
    So I see that it is a recommendation, not a mandate. But, how do I launch SPIN code from PASM? Do I need to manage copying (a fresh version of) the SPIN interpreter from ROM to a cog (probably can count on using cog0) and then starting that cog (running the SPIN interpreter, which starts at $00?). Or, is it reasonable to count on the fact that the initial boot process loaded cog0 with the SPIN interpreter PASM code, and it is still intact, so if I didn't restart cog0 during the bootloader execution, can I just (re)launch cog0 with all 512 registers' contents intact? (That also presumes that every SPIN binary has an entry point of $0010 - is that a valid assumption?)

    Sorry for the length and detail, but it seems that to do this correctly all these things need to be considered. BTW, I did look at the ybox2 bootloader and I don't believe it operates this way. I'd be surprised if this hasn't been implemented before, but I can't find an example.

    Thanks for any help available.
  • BigFootBigFoot Posts: 259
    edited 2011-02-04 12:43
    We use the Amtel AT24C512B-TH25-B in all of our products.
  • Mike GreenMike Green Posts: 23,101
    edited 2011-02-04 13:50
    It's not that it's impractical to launch Spin code from a user's Propeller Assembly code, it's just that the details of how to do it are too complex to describe properly in a few paragraphs.

    There's a bootloader that's part of FemtoBasic that's is designed for use in other programs. It can load and execute a Spin program from a file from an SD or micro-SD card or from an I2C EEPROM. Download FemtoBasic and look in sdspiFemto.spin at the method bootEEPROM. This reads a Spin program from an EEPROM into the Propeller's Hub RAM, then starts up a Spin interpreter for that program in its own cog using a COGINIT instruction. These routines have been modified and used in all kinds of other programs and the Spin startup code was originally provided by Chip Gracey. You can use sdspiFemto in your own program or simplify it first (like stripping out the SD card routines) or just look at how it starts up a Spin interpreter and use that in your program. As I mentioned, the Propeller Backpack uses a simplified version of this scheme for its bootloader. The YBox2 uses a variant for doing "overlays" and for updating its own bootloader which works over the Internet.

    KyeDOS is an "operating system" that uses Kye's SD card library for its I/O and can run programs off an SD card (here)

    Sphinx is another "operating system" and I/O library that can run programs off an SD card and includes a Prop-native Spin compiler (here).

    There's another bootloader based on sdspiFemto, but uses Winbond Flash memory for its Spin program files here.

    There's an old "Propeller Operating System" for use with EEPROM only here. Look at posting #28 for the last version. This is the predecessor of the bootloader in sdspiFemto.
  • agsags Posts: 386
    edited 2011-02-04 16:23
    Thanks, Mike!

    I've looked at the ybox2 bootloader. I will look at the sdspiFemto.spin code.

    I already tried searching for the Propeller Backpack bootloader you mentioned in your previous reply, but could not find it. Could you point me towards it?
  • Mike GreenMike Green Posts: 23,101
    edited 2011-02-04 16:27
    The bootloader is part of the Propeller Backpack firmware. There are links to it near the bottom of the product page here (Propeller Backback Monitor). Also look at the Backpack's documentation for a description of how the Monitor works.
  • agsags Posts: 386
    edited 2011-02-04 21:26
    Thanks again, Mike. That is a great example. Nice clean code, too.

    I think I can infer most of what I need from that example (and I don't need to fully understand this specific item) - but is there anything more to be learned about the "interpreter" (seems to be a common register name for this value) magic code that's loaded as the destination register value in the PASM coginit call after the EEPROM code is copied down into RAM? It looks like it's setting the PAR register to $01 and the PASM start address as $3C01 (well beyond 512 cog RAM). Just curious.
  • Mike GreenMike Green Posts: 23,101
    edited 2011-02-04 21:44
    The $3C01 is the start of the Spin interpreter in ROM. That area of ROM is encrypted (and decrypted on the fly by the COGINIT) although the encryption has been broken and the source code of the Spin interpreter has been publicly posted. There's another piece of information in PAR that tells the Spin interpreter where to find the 16 byte control block that defines the Spin program in hub memory. This control block starts at location zero by default. I don't remember the details, but the information is available.
  • Oldbitcollector (Jeff)Oldbitcollector (Jeff) Posts: 8,091
    edited 2011-02-05 07:59
    Looking at the popular current offerings, there just isn't a reason to not use a bootloader any more.
    (Starting to feel like I should capitalize on this in my personal Propeller use.)
    Propeller Protoboard		64K
Propeller Demoboard		256K
Propeller PPDB			32K (socketed)
C3				64K
GG Propeller Platform		64K
Spin Studio			64K (socketed)
PropRPM				32K (socketed)

    OBC
  • agsags Posts: 386
    edited 2011-02-05 08:38
    While EEPROM related, I'm afraid my interest (and questions) has been really about bootloading using EEPROM. I don't know if it's worth starting a new thread, though. I will do so if that's prefered. I think I'm almost done...

    I'm wondering if the delay (mimicing Propeller "cold" startup procedure) in the following code is really needed?
    '-----------[ boot_ram ]-------------------------------------------------------
'Run user program. 
boot_ram rdbyte clkval,#$0004 'If xtal/pll enabled, start up now
and clkval,#$F8 ' while remaining in rcfast mode.
clkset clkval
:delay djnz time_xtal,#:delay 'Allow 20ms @20MHz for xtal/pll to settle.
rdbyte clkval,#$0004 'Switch to selected clock.
clkset clkval
coginit interpreter 'Reboot cog with interpreter.

    I see what it's doing, but can't figure out why. Is it necessary for an absolutely robust design (maybe catching some bizarre corner case), necessary for even modest reliablity (larger failure rate if not used) or absolute overkill (not ever needed)?

    Given that the Propeller has been already been running the PASM code at full speed to load code from EEPROM to RAM, I would expect it to be fully stabilized. I'd even offer this code is destabilizing, as it takes a running Prop, slows it down, then speeds it right back up to where it was. Am I mistaken here?
  • Mike GreenMike Green Posts: 23,101
    edited 2011-02-05 09:27
    Yes, it is necessary. It wouldn't be there if not. The ROM bootloader runs using the internal fast RC clock because that's the only one (other than the slow RC clock) that's sure to be functioning. It's not an accurate clock and the frequency can vary widely depending on the specific chip, temperature, and supply voltage. That's why a self clocking protocol is used for downloading. The RC clocks are not accurate enough for standard asynchronous serial I/O.

    Oscillators and phase locked loops take time to start up and become stable. The boot code has no way of knowing whether the oscillator and PLL are already running and stable, so a delay is inserted to insure that that's the case. If you look at the bootloaders that I've written, they save the clock frequency and mode before loading the new Spin program, then compare the new values loaded with the program with the old saved ones. If there's no change, the bootloader skips this clock change code and just starts up the Spin interpreter.
  • agsags Posts: 386
    edited 2011-02-05 10:06
    Mike:

    Excellent explanation! I was partially correct but could have gotten into trouble, but with your response now I get it. I am used to always writing my SPIN code with just one clock setting (not that that might not change for some reason) and it didn't occur to me that the new SPIN code being loaded might not use the same clock speed as the previously running code (the bootloader itself, in this case), and will need time to stabilize. In any other case, regardless of how many cogs are running or whether it's SPIN or PASM, it's always the same clock across execution units.

    The code snippet I provided went through the stabilization process regardless. I think your method of checking to see if new clock <> old clock and only then stabilizing is great. For just the cost of a simple store & compare, you avoid the slow clock delay when not needed, but when needed it's completely robust. Of course, it's only 20mSec, so either way it's not a big deal (especially compared to the time to load from EEPROM over I2C) but understanding why it IS necessary is very helpful. Thanks again.
  • Ding-BattyDing-Batty Posts: 302
    edited 2011-02-05 22:37
    Oldbitcollector wrote: »
    Looking at the popular current offerings, there just isn't a reason to not use a bootloader any more.
    (Starting to feel like I should capitalize on this in my personal Propeller use.)
    Propeller Protoboard        64K
[COLOR=red]Propeller Demoboard        256K[/COLOR]
Propeller PPDB            32K (socketed)
C3                64K
GG Propeller Platform        64K
Spin Studio            64K (socketed)
PropRPM                32K (socketed)
    OBC

    I think the entry for the DemoBoard is wrong -- the Propeller datasheet schematic says the part is the 24LC256, which is 256Kbits, or 32Kbytes.
  • agsags Posts: 386
    edited 2011-02-08 14:55
    Does anyone know if the schematic for the Propeller Proto Board (USB) is incorrect, or if the supplied datasheet for the 512kb EEPROM (here: http://www.parallax.com/Portals/0/Downloads/docs/prod/compshop/602-10001-32KBEEPROM(SMT).pdf) is incorrect? (I suspect the latter).

    I've seen many schematics with the AT24C512 EEPROM and pins 1-3 are tied low. The datasheet lists pins 1 & 2 as Address 0 and 1, respectively, and pin 2 as "NC". It sure look looks to me like pin3 really is Address 2 (and that would explain the odd "%10100<a1,a0><r,w>" START word).
  • Mike GreenMike Green Posts: 23,101
    edited 2011-02-08 22:01
    The AT24C512 only allows two address select pins. The AT24C512B allows all three for compatibility with Atmel's competitors.
  • agsags Posts: 386
    edited 2011-02-08 22:02
    I think I found the answer. The part actually being used is an updated version, the AT24C512B, datasheet here: http://www.atmel.com/dyn/resources/prod_documents/doc5297.pdf It has address pins A0:2 and uses the expected three-bit device address following the %1010 sequence.

    Edit: Mike, you're too fast. Beat me by a minute...
Sign In or Register to comment.