Shop OBEX P1 Docs P2 Docs Learn Events
Does the Propeller always have to have a 32K eeprom attached? — Parallax Forums

Does the Propeller always have to have a 32K eeprom attached?

LoopyBytelooseLoopyByteloose Posts: 12,537
edited 2013-08-10 11:59 in Propeller 1
I have had several 40pin dip Propeller around since they first came out, so I recently built a board to press one into use. My cashe of Propeller Proto Boards was beginning to run low.

Foolishly, I managed to use a 4K eeprom instead of a 32K eeprom and got a Eeprom verify error.

I thought that just removing the eeprom entirely would allow me to load to RAM, but that produced yet another error. So it seems that the eeprom is mandatory. Is that correct? I had just presumed that the Propeller would load and run without one.

I now have the right 32K eeprom installed and the build is running great. I do know I can use larger eeproms. And it does seem that even the 4k eeprom will work as a dummy to permit loading the RAM.

I am just wondering the 'sans eeprom' was all in my imagination.

Comments

  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2013-08-06 09:10
    As long as you're just saving to RAM, you should not get any errors without an EEPROM attached. Saving to a small EEPROM will give you an error though, since all 32K bytes are always written and verified.

    -Phil
  • mindrobotsmindrobots Posts: 6,506
    edited 2013-08-06 09:43
    With PropForth, I often run slave Propellers that don't initially have anything more than power and decoupling capacitors connected to them (plus pins 29-31 connected to the master for loading and serial I/O). They run fine without an EEPROM (the master pretends to be an EEPROM for booting) and the master also provides clock through an I/O pin off one of its counters.

    Happy little Propellers, they are!
  • Cluso99Cluso99 Posts: 18,069
    edited 2013-08-06 12:21
    Search the forum for my posting on 24C64 or 24LC64 with a prop. There is code there that will work for you. The problem is that you cannot program the eeprom from the PropTool because you get an incorrect checksum. So you have to do it in two stages and create a false checksum. Its all there in the thread.
  • LoopyBytelooseLoopyByteloose Posts: 12,537
    edited 2013-08-06 12:54
    I guess I should have mentioned that I got the eeprom error message in bst when I pulled the eeprom and attempted to just load RAM. I suppose bst might have a different error message regime than the Prop Tool.

    I was aware that PropForth will load a slave Propeller via the I2C. I was not aware that someone had actually used to 16k eeproms.

    This is the first time since I got my first Propeller chips that I have had any eeprom messages at all.
  • localrogerlocalroger Posts: 3,451
    edited 2013-08-06 16:57
    If you run with a small EEPROM you will get the error no matter how small your program is, but if your program fits in the small EEPROM it will still run because the EE does get written and read back when the Prop reboots. The loader just knows that its 32K scan didn't match what it downloaded, it doesn't know you don't care about the upper 24K.
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2013-08-06 18:30
    localroger wrote:
    ... but if your program fits in the small EEPROM it will still run ...
    I'm not sure that's the case. Because of address wraparound, the lower bytes of the EEPROM will get written with the upper (null) bytes of the program, since they are written last. To alleviate this, you'd have to use a method of programming the EEPROM other than the Prop's bootloader.

    -Phil
  • Cluso99Cluso99 Posts: 18,069
    edited 2013-08-07 03:28
    Phil is correct. You have to use a specially written loader to program the smaller eeprom and it should recalculate the checksum. On boot the prop will load n copies of the smaller eeprom (n being 32KB / eeprom size) and then verify the ckecksum. This is why you have to recalc the checksum.
    The reason the loader works with small eeproms is that the start address is only sent once and successive reads take place causing the address to wrap internally in the eeprom.
    If you really require the balance of hub cleared, then you program must do this in main - use longfill for preference.
    I have done this and it works.
  • localrogerlocalroger Posts: 3,451
    edited 2013-08-07 20:23
    I stand corrected. I didn't realize there is a checksum.

    Really, a checksum? The proptool verifies the EE write byte for byte and there's a checksum too?
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2013-08-07 20:30
    Yes, there's a checksum, but it's verified only during upload, not upon reboot from EEPROM. This allows you to dynamically modify start-up data in EEPROM without having to recompute the checksum.

    -Phil
  • localrogerlocalroger Posts: 3,451
    edited 2013-08-07 20:32
    Well then that would generate a nag but the program would still run if it fit in the undersized EE, right Phil?
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2013-08-07 20:38
    No nags upon reboot with a mismatched checksum. The prop simply doesn't care at that point. The problem is with the bootloader loading all 32K bytes into a wrapped-around address space. It not only fails to verify, but the data you really want (i.e. the lower bytes) get overwritten with null bytes from upper EEPROM.

    -Phil
  • David BetzDavid Betz Posts: 14,516
    edited 2013-08-07 20:45
    Phil Pilgrim (PhiPi) wrote: »
    No nags upon reboot with a mismatched checksum. The prop simply doesn't care at that point. The problem is with the bootloader loading all 32K bytes into a wrapped-around address space. It not only fails to verify, but the data you really want (i.e. the lower bytes) get overwritten with null bytes from upper EEPROM.

    -Phil
    What happens if you write an image with multiple copies of the lower bytes or even zeros all the way up to the last 8k on an 8k byte eeprom? Do you then get a programming error but a working eeprom?
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2013-08-07 21:07
    As long as the last bytes written (that overwirte the first ones) form a valid program, you should be okay -- and as long as the checksum is correct. If the checksum is wrong, the Prop-resident loader will not copy the uploaded RAM contents to EEPROM.

    -Phil
  • Cluso99Cluso99 Posts: 18,069
    edited 2013-08-08 05:04
    I cannot recall everything precisely. The checksum is held in byte $0005 in hub for from/to eeprom. If you look at my thread the code and operation is fully detailed. I am away so cannot check atm.
  • David BetzDavid Betz Posts: 14,516
    edited 2013-08-08 05:25
    Phil Pilgrim (PhiPi) wrote: »
    As long as the last bytes written (that overwirte the first ones) form a valid program, you should be okay -- and as long as the checksum is correct. If the checksum is wrong, the Prop-resident loader will not copy the uploaded RAM contents to EEPROM.

    -Phil
    It should be easy enough to write a small program that will convert an 8k EEPROM image into a full 32k image with the relevant 8k at the end and the correct checksum. Then you'd have an image that could be loaded with the Propeller Tool directly.
  • UnsoundcodeUnsoundcode Posts: 1,532
    edited 2013-08-08 05:44
    I don't think I ever tested this to it's limits but I did play around with a modified bootloader that could load several small and individual binaries into a single 32K EEPROM so loading a single binary less than 32K can also be done as has already been said. Check the following link, I never really did anything serious with this, it was just a time I went through a bootloader phase.

    http://forums.parallax.com/showthread.php/130615-Slot-Programming-the-Propeller

    Jeff T.
  • localrogerlocalroger Posts: 3,451
    edited 2013-08-10 11:59
    Ouch, forgot about the top overwriting the bottom on wraparound.

    Does seem you could program the smaller EEPROM from a bin or a 32K source using an external programmer, then it should boot the Prop properly, but that would be a bit of a pain compared to using the PropTool.
Sign In or Register to comment.