clear eeprom on BS2SX
okcengineer
Posts: 8
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!
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
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.
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.
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.
Jeff T.
Jeff T.
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?
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
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
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...
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!
I guess my only choice is to get a fresh Stamp.
Thanks for your help guys.
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.
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
How about replacing the EEPROM and starting fresh that way?
DJ
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.
I, too, am quite confused why a "simple write over" doesn't do the trick.
DJ
Would it be possible to add two object files ? One unknown and one with ability to patch the original code?
Just thinking out loud.
Did you run the "vipe EEPROM" in all of them as Jeff T suggested?
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!
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.
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!
http://forums.parallax.com/showthread.php?84569-Clear-EEPROM
Although you may have already attempted some of this.
DJ
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.
DJ
regards
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?
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!