Shop OBEX P1 Docs P2 Docs Learn Events
eeprom file format — Parallax Forums

eeprom file format

aeae Posts: 7
edited 2013-02-02 07:16 in Propeller 1
Hi All,

What is the definition of the·initialization section(first 16 bytes) of the eeprom file. That is saved from propeller Tool.

Comments

  • BradCBradC Posts: 2,601
    edited 2009-11-12 11:58
    ae said...
    Hi All,


    What is the definition of the initialization section(first 16 bytes) of the eeprom file. That is saved from propeller Tool.

    Bytes :
    0-3 Clock speed
    4 : Clock Mode
    5 : Checksum
    6-7 : PBase - Start of object
    8-9 : VBase - Start of Variables
    10-11 : DBase - Start of Stack
    12-13 : PCurr - Pointer to start of first spin object to run
    14-15 : DCurr - Stack pointer

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    If you always do what you always did, you always get what you always got.
  • aeae Posts: 7
    edited 2009-11-12 14:15
    How can I calculate the Checksum?
  • BradCBradC Posts: 2,601
    edited 2009-11-12 14:18
    ae said...
    How can I calculate the Checksum?

    Adjust it so adding all 32k bytes together == 0

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    If you always do what you always did, you always get what you always got.
  • aeae Posts: 7
    edited 2009-11-12 14:28
    Initialization section also inside the 32K area so it is not possible to find sum because the checksum byte also in it.
    It must be sum of some part of the memory area.
  • BradCBradC Posts: 2,601
    edited 2009-11-12 14:49
    ae said...
    Initialization section also inside the 32K area so it is not possible to find sum because the checksum byte also in it.
    It must be sum of some part of the memory area.

    The checksum must be adjusted so the sum of all bytes in the 32k image == 0

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    If you always do what you always did, you always get what you always got.
  • Mike GreenMike Green Posts: 23,101
    edited 2009-11-12 15:12
    Usually this is done by setting the checksum to zero, then adding all the bytes in the 32K image together. Subtract the result from zero and store that in the checksum byte.
  • David BetzDavid Betz Posts: 14,516
    edited 2011-06-28 06:49
    Sorry for bumping this ancient thread but I'm trying to figure out why my checksum calculation isn't coming out quite right. I used BSTC to create a Spin binary using the -b option and added up all of the bytes in the resulting image and I get 0x14 not zero. However, the binary image loads successfully into the Propeller so I assume the checksum must be correct. Why don't the bytes add up to zero?
  • David BetzDavid Betz Posts: 14,516
    edited 2011-06-28 07:08
    Duane Degn wrote: »
    Are you add all the bytes in the image?

    From reading the thread, the checksum is used for just the first 32 bytes.

    Yes I was adding all of the bytes in the image. The message from Mike Green earlier in this thread said to sum all 32k bytes. Actually, my image isn't a full 32k bytes so I was only summing the bytes that were actually part of the .binary file but I don't think that should matter since any remaining bytes would be zero and not affect the checksum.
  • Duane DegnDuane Degn Posts: 10,588
    edited 2011-06-28 07:10
    David Betz wrote: »
    Yes I was adding all of the bytes in the image. The message from Mike Green earlier in this thread said to sum all 32k bytes. Actually, my image isn't a full 32k bytes so I was only summing the bytes that were actually part of the .binary file but I don't think that should matter since any remaining bytes would be zero and not affect the checksum.

    Sorry David, I read the original stuff too fast. I thought my post was only there a few seconds before realizing my error so I deleted it. (First time ever to delete a post.)
  • Dave HeinDave Hein Posts: 6,347
    edited 2011-06-28 08:21
    I was always puzzled why the checksum added up to $14. Then I found out that the checksum includes the "extra" bytes that are shown in the hex display in the "View Info" screen (function key F8). The extra bytes at the end are $FF, $FF, $F9, $FF, $FF, $FF, $F9, $FF. These are not included in the binary file, or in the EEPROM.

    These bytes are added to the beginning of the stack at run time. The extra bytes cause a Spin cog to jump to the ROM address $FFF9 when it terminates. The code at $FFF9 contains a few Spin bytecode instructions to get the cog ID and issue a cogstop.

    If you add the extra bytes to $14 you will get $00.
  • David BetzDavid Betz Posts: 14,516
    edited 2011-06-28 08:53
    Wow! I never would have guessed that. I guess I can just assume that the checksum should add up to $14. Thanks for explaining these odd details!
  • WossnameWossname Posts: 174
    edited 2013-02-02 07:16
    Dave Hein wrote: »
    The extra bytes at the end are $FF, $FF, $F9, $FF, $FF, $FF, $F9, $FF. These are not included in the binary file, or in the EEPROM.

    Version 1.3.2 of the Propeller Tool truncates saved binary files immediately before the FFFFF9FFFFFFF9FF sequence would normally appear in the eeprom. But the saved eeprom file itself DOES in fact contain that byte sequence.
Sign In or Register to comment.