Shop OBEX P1 Docs P2 Docs Learn Events
clear eeprom on BS2SX — Parallax Forums

clear eeprom on BS2SX

okcengineerokcengineer Posts: 8
edited 2011-04-14 11:59 in BASIC Stamp
Working with a product that I did not design (well, I designed the board layout, but not the PBasic firmware. The firmware author is unavailable). I am having to reload the program on a customer's product. Problem is, I need for the EEPROM to be totally clear to delete any pre-existing variables, so the program can start with a blank slate.

For example, there is a variable that holds the product's serial number, and another variable that sets a timing interval for the product. There's also a variable for holding an IP address and one for a port number. I need these to be gone entirely so they can be refreshed with the latest firmware.

Also, I am at ground zero when ti comes to Basic Stamp programming. I can program in Microsoft VB and in intel MCS-51 assembly language, but PBasic, and the way the Stamp works, is totally unfamiliar to me.

I tried running a simple program that would write the value 255 to all EEPROM memory slots, and then reloading the original program, but the variables are still there:

for n=0 to 2047
write n, 255
next

I am proud of myself for figuring out that much, but what is it worth when it doesn't accomplish what I need?

Can someone tell me what I am missing?

Thanks a bunch!

Comments

  • Mike GreenMike Green Posts: 23,101
    edited 2011-04-12 12:30
    The BS2sx has several pages of memory (called "slots") each of which can be downloaded separately from the Stamp Editor. It may be that your BS2sx has an initialization program in one of the other slots that's RUN if the variables are uninitialized (zeroes), initializes the variables, then restarts the default program in slot #0 with the variables preset. Look for another source file for this short initialization program. That's what you have to change and re-download.

    Alternatively, the initial data may be compiled into the main program with DATA statements with the initialization code copying the data to the program's variables. This initial data is part of the program itself and would be reloaded with the rest of the program, so the EEPROM clearing would have no effect.
  • okcengineerokcengineer Posts: 8
    edited 2011-04-12 14:27
    ADDITIONAL INFORMATION:

    I think I may need to be more specific about my situation.

    First, the source code is not available to me. It was written several years ago by someone who is no longer available, because the company has since gone out of business. As I mentioned in my post, I designed the board layout, but the firmware was written by someone else. If I had the source code, I wouldn't have any problem sharing it with you, but it's possible that if I did have the source code, I could probably figure it out on my own.:innocent:

    Specifically the value I am trying to clear is one that is set by the program, keeping track of how many records are contained in a separate memory chip. I had to replace a defective memory chip, so the new chip is blank, but because of the tracking value contained in the Stamp's non-volatile memory, the program believes that there are still records on the memory chip, so it starts saving memory information at a location too far in to the memory, rather than at location byte 0. I hope I am explaining this clearly. It's easy for me to visualize when I am looking at it, but I am not sure I can describe it accurately.

    Remember, too, that I am a total neophyte when it comes to Basic Stamp architecture. I may be able to figure this out on my own if I had the time to spend studying the documentation, but this needs to get back to the customer ASAP. I was hoping there'd be a simple command or procedure that would just write FFs into all of the memory slots, but I guess I am just dreaming.

    I hope this gets a few brain juices flowing. I apreciate any help you can give.
  • UnsoundcodeUnsoundcode Posts: 1,532
    edited 2011-04-12 16:46
    Hi, the BS2sx has 8 programmable "Slots" that each "own" 2048 bytes of the 16Kbyte EEPROM memory. Each slot can only write to its "owned" 2048 Kbytes of memory space. Its not possible to write a program that will clear every memory location because the program needs its own EEPROM space to reside in. The following example programmed in each of the 8 "Slots" and the RUN instruction incremented by 1 in each succesive slot will clear 16120 memory locations the remainder being overwritten by program code
    cnt VAR Word
    main:
    FOR cnt=0 TO $7DF
    WRITE cnt,$FF
    NEXT
    RUN 1
    

    Jeff T.
  • UnsoundcodeUnsoundcode Posts: 1,532
    edited 2011-04-12 17:53
    Hi vaclav_sal, a question I also pondered, I am assuming that okcengineer has a binary of the program.

    Jeff T.
  • vaclav_salvaclav_sal Posts: 451
    edited 2011-04-12 17:56
    Jeff,
    he aslo already did same EEPROM cleanup.
    How do you build binary file and how do you load it to the BS?
    Can it be done using editor?
  • UnsoundcodeUnsoundcode Posts: 1,532
    edited 2011-04-12 18:07
    Hi vaclav_sal, I don't know for sure maybe okcengineer can expand.

    Some people may prefer to distribute their software as a binary rather than the full source to protect their work from piracy, to generate a binary you go to the File menu and Generate Object Code in the PBasic IDE.

    Jeff
  • vaclav_salvaclav_sal Posts: 451
    edited 2011-04-12 18:38
    Thanks Jeff
    I guess to resolve this - reverse engineering is one of the solutions. Hope the external EEPROM address is known.
    Or the product ID etc. Assuming the author did not encode anything.

    I;ll do some test coding tomorow.


    Vaclav
  • okcengineerokcengineer Posts: 8
    edited 2011-04-13 06:42
    Sorry for the confusion. Let me explain...

    I do have the editor that I used for creating the small program that I had hoped would clear the memory (but it didn't). I do not have the source code for the product. What I do have is an executable file that contains the tokenized program embedded within it (sort of like an executable ZIP file) that, when run, finds the serial port that the product is connected to, and downloads the compiled/assembled/tokenized program to the Stamp.

    Here's a couple of screen captures, if you can see them...

    stamp_cap1.PNG
    stamp_cap2.PNG


    I don't know how this was accomplished, my being a Stamp moron, but it made it easier for the production personel to load the firmware into the Stamp. This is probably the binary code that Jeff T was talking about.

    I have no need to make any changes to the program code, so it doesn't really help for me to have the source code. All I'd like to do it restore the Stamp to what might be considered a factory-fresh state. Jeff, I will try your code snippet and let you know how it works. Thanks!
    351 x 361 - 19K
    395 x 377 - 93K
  • okcengineerokcengineer Posts: 8
    edited 2011-04-13 07:29
    Ah, well... no luck. When I run that code snippet, I then run another snippet that reads and displays the eeprom contents, it shows the y character repeatedly for a while, and then some binary gibberish, and it will then show some of the ascii from the original program. In fact, it acts as though it's running the original program. And then if I reload the original program, the same problem is still there.

    I guess my only choice is to get a fresh Stamp.

    Thanks for your help guys.
  • vaclav_salvaclav_sal Posts: 451
    edited 2011-04-13 07:31
    I am going to try using the "create object code " later today. I need to work for Uncle Sam for now!!!!

    To "speed" things up.- after you load the object file - using the BS editor - can you use the "memory map" feature?
    If so change the display to ASCII and just look for the items of interests - product ID, external EEPROM ( not the program one) address etc.

    The problem I see with erasing the program EEPROM ( and you have already done that ) the program EEPROM gets overwritten every time you download the program. It should not make any difference if it is text source or object file.

    I am not sure if it is possible to add a code / patch the existing program without complete reload.

    Vaclav

    PS I still think we are not communicating properly - using your teminology - the program EEPROM gets set to new program ( factory default ) every time you load it.
    Your original concern was to enable external EEPROM (data) to address 0.
    This address is currently set by the program to last used location - am I right?
    So we need to find where in the program is this done.
    I am assuming that at least the base address of the data EEPROM is visible somewhere in the program.
  • vaclav_salvaclav_sal Posts: 451
    edited 2011-04-13 10:10
    Good news / bad news.
    StampLoader loads but does not show program - not surprised, it is not needed.
    I added DATA "Hello" to each of my BS2e modules and view the object file with Notepad.
    I can see these DATA .
    So, it should be posible to modify the object file itself.

    Of course there is a catch - the object file has a checksum and it will probably fail if it is not correct.

    I'll try that next

    And it failed the check sum as expected.
    Besides that - only ASCII characters are visible / identifiable in the object file.
    Back to the drawing board!

    Vaclav
  • davejamesdavejames Posts: 4,047
    edited 2011-04-13 11:38
    I guess my only choice is to get a fresh Stamp.

    How about replacing the EEPROM and starting fresh that way?

    DJ
  • okcengineerokcengineer Posts: 8
    edited 2011-04-13 11:52
    Well, I really appreciate all your efforts on this!

    It seems like such a big job just to clear out one memory location. There are lots of non-program memory locations used, but I can deal with all of them except this one -- the external memory pointer. If I knew where that was on the eeprom, I'd go right to it and zap the bugger.
  • davejamesdavejames Posts: 4,047
    edited 2011-04-13 11:56
    If there's ever a resolve to this, please post.

    I, too, am quite confused why a "simple write over" doesn't do the trick.


    DJ
  • vaclav_salvaclav_sal Posts: 451
    edited 2011-04-13 11:59
    As long as the unwanted "variables" - product ID etc are in the object file replacing program EEPROM will not accomplish anything.

    Would it be possible to add two object files ? One unknown and one with ability to patch the original code?
    Just thinking out loud.
  • vaclav_salvaclav_sal Posts: 451
    edited 2011-04-13 12:03
    DJ got a point - how many modules / slots are actually used by the program?
    Did you run the "vipe EEPROM" in all of them as Jeff T suggested?
  • okcengineerokcengineer Posts: 8
    edited 2011-04-13 12:40
    Wow, it's so easy to overlook the minor points, I apologize for my lack of detail.

    The variables are not contained in the source code. They are set, upon first running the program, using a menu. For example, one of the menu items is "Set Serial Number." The user selects that, then types in a four digit number. That value is stored somewhere in the eeprom, so even if I download the entire program, that memory location is unaffected. It is the same with the external memory pointer, which is the one thing I am trying to clear out. But there's no menu selection for clearing out that location, it's all done internally.

    And yes, I ran Jeff's code in all eight slots. It was effective up to a point, but it didn't get it all. See my earlier post @9:29.

    Since I did not write the original program, I have no way of knowing how many slots it fills. But I can see that, running the download executable, it shows to be writing to all eight slots, but whether it's actually doing it or not, I don't know.

    I could replace the eeprom, I guess. I can handle a soldering iron. Just wish it didn't have to come to that. Seems like there oughta be an easier way.

    I'm sorry to be such a bother!
  • vaclav_salvaclav_sal Posts: 451
    edited 2011-04-13 12:53
    Hey, it " ain't no bother"!
    The StampLoader loads fix lenght file and the way to tell is to look at it in Notepad as I did, sort of.
    (I did not load single slot program - I'll check this)

    Here is a crazy idea - what would happen if you have no external EEPOM for your data?
    Will you program complain or just reset this crazy pointer to 0?
    Another thing - since you have a menu you must have ASCII data for your text. Maybe it is in one slot only.
    But that still wont help much.
  • okcengineerokcengineer Posts: 8
    edited 2011-04-13 13:13
    In running the simple verification program -- where it runs a READ loop and "debugs" it to the terminal -- I can still see remnants of the ascii codes that the old program left. And it does something weird... depending on which slot it's reading, it may get to a point and act like the OLD program is running again. I hope I can explain this. There's a part of the original program where it's waiting for a response from another peripheral. It essentially is a loop, like this:

    WAIT1 [delay of several seconds]
    WAIT2 [delay of several seconds]
    WAIT3 [delay of several seconds]
    WAIT4 [delay of several seconds]

    etc. But the odd thing is, when I am just reading the memory, when it gets to this part of the code, it actually starts running the program. It won't just say "WAIT" and then go on to the next memory location to read, it starts running the loop. Strange.

    Also I had an idea that didn't work, but maybe someone can figure out a way to make it work. I wrote a program that is nothing but DATA directives, i.e.:

    DATA $FFFF, $FFFF, $FFFF, $FFFF, $FFFF, $FFFF, $FFFF, $FFFF, $FFFF, $FFFF, $FFFF, $FFFF
    DATA $FFFF, $FFFF, $FFFF, $FFFF, $FFFF, $FFFF, $FFFF, $FFFF, $FFFF, $FFFF, $FFFF, $FFFF
    DATA $FFFF, $FFFF, $FFFF, $FFFF, $FFFF, $FFFF, $FFFF, $FFFF, $FFFF, $FFFF, $FFFF, $FFFF
    (Total of 172 lines)

    etc. I inserted as many of these data directives as the editor would allow. It wound up to be a total of 2,064 $FFFFs. Then included a RUN command. Ran the program with RUN 0, RUN 1, RUN 2, etc., then reloaded the original program to see if the user data (serial number, etc) was still there. It was, which means this idea failed. But if someone knows of a way to use a variation of this to pack the data throughout the eeprom, maybe we can finally get this figured out. Maybe the RUN command doesn't work like this.

    Thanks again!
  • davejamesdavejames Posts: 4,047
    edited 2011-04-13 15:51
    I found this old thread:

    http://forums.parallax.com/showthread.php?84569-Clear-EEPROM


    Although you may have already attempted some of this.


    DJ
  • UnsoundcodeUnsoundcode Posts: 1,532
    edited 2011-04-13 16:04
    Okcengineer, the snippet I gave you will overwrite the EEPROM contents “owned” by each slot except for 32 bytes in each that contains the program code. The space occupied by the program code can be seen in the memory map of the IDE.

    The snippet will overwrite more than 1600 bytes. Your test program to read the EEPROM should display over 1600 bytes with a value range of 0 to 255. If this is not happening then you have something wrong in your code. I have a feeling that one thing that might be wrong is your DEBUG instruction in the READ routine, it should look something like this.

    READ cnt,value
    DEBUG cnt,” “,DEC value,CR

    The 32 memory locations that do not get overwritten by the above routines are almost certainly going to get filled with the program code of your final application. You do not need a replacement Stamp or a replacement EEPROM from what I see.

    If you want to run a READ test after clearing the memory post the code you have as an attachment so that we can help with it. If there is a memory location that contains an index thats read by your program is initializing it with a value of 255 what you really want to do. What is the maximum count of the index , perhaps the value is greater than 255 and is contained in two consecutive locations. Things to consider.

    Jeff T.
  • davejamesdavejames Posts: 4,047
    edited 2011-04-13 16:44
    ...Hi Jeff!

    DJ
  • UnsoundcodeUnsoundcode Posts: 1,532
    edited 2011-04-13 17:25
    Hi there Dave.......we are off topic here thats not good :o)

    regards
  • vaclav_salvaclav_sal Posts: 451
    edited 2011-04-13 21:01
    Allow me to throw this into the discussion.

    Using just an editor load and run this program

    DATA “HELLO”
    Main:
    END

    Now check the program EEPROM map.
    Observe “HELLO” in lower part of memory map.

    Now load and run

    Main:
    END


    Now check the program memory again. Do you see any DATA?

    As expected – new program load clears the EEPROM and loads only the new tokens.
    There is no need to do any clearing of the EEPROM.
    (Besides if we do WRITE from 0 to $700 it takes a while – even on BS2e!)

    And in the subject of this discussion – the unwanted memory address is generated by the program itself.

    Maybe we should ask – what will happen when the program runs out of this external memory space?
  • okcengineerokcengineer Posts: 8
    edited 2011-04-14 11:59
    Well, as much effort as you guys have put into this, I can announce that, for me at least, the issue is moot. The customer has decided to replace the unit altogether.

    It hasn't been without its benefits: I have learned a little more about the Stamp, and have found some good people to help me. And if I had more time to devote to this issue, I would go ahead and try some of the newer suggestions. But this has already consumed more of my productive time than it should have. It's a great relief to not have to worry about it anymore.

    Thank you very much, everyone!
Sign In or Register to comment.