after finding that our piece of code that we had implemented was giving off some really really weird values (0,3,2,1,0,3,2,1,…etc) our programming team (well 2/3 of it… one person was sleeping most of the time 
) spent a few hours of debugging to find, that we had some errors in the code that we didnt know about before, but more importantly we had some bad scratchpad ram locations in last years rc (3 total so far i think).
has anyone else had any problems with this?
*Originally posted by ChrisA *
**but more importantly we had some bad scratchpad ram locations in last years rc (3 total so far i think).has anyone else had any problems with this? **
I vaguely remember seeing something on the Parallax BASIC Stamp discussion list about someone having problems with some bad memory locations in either the scratchpad RAM or in EEPROM. If I remember right, it was related to a particular rev mod of the BASIC Stamp2.
after writing a code to test each of the scratchpad ram locations we found that none of them seem to be bad… but if we use them in our coding they give us strange and also inconsistent values
if we switch from these bad sectors to what we have deemed as good locations the code works just fine and the values are what they should be.
the bad locations when used in our robots code will always give data in a patern such as the one that i posted earlier (0,3,2,1,0,3,2,1…etc) and have no relation to any data given to the locations by any piece of our code
i’ve heard of scratchpad ram, but i don’t know what it is. i probably should, seeing as i’m 1/2 the programming team. 
anyone care to explain?
ooh i wish keith were here… 
ill try my best here and maybe someone can help me out
ram (standing for random access memory) is a memory that you read and write numbers to. it is erased every time you disconnect power for about 10-15 secs (or however long it takes power to discharge from the circuit). when you download code into the robot it is stored into whats known as eeprom which is a type of memory that doesnt get changed until someone goes in and changes it (ie downloading new code). the scratchpad ram is what is used when you are trying to save a temporary value that will be changed at different points in the code (aka a variable). you have 62 scratchpad ram locations total in each bank.
to sum this all up…
scratchpad ram is the physical memory area inside the robot controller where all your variable values are stored.
hope that helps
(dont feel sad for not knowing… i dont know a lot of things and im about 1/3 of my programming team) (well maybe 1/4… keith is probably 1/2 of our team )
*Originally posted by ChrisA *
**after writing a code to test each of the scratchpad ram locations we found that none of them seem to be bad… but if we use them in our coding they give us strange and also inconsistent values
if we switch from these bad sectors to what we have deemed as good locations the code works just fine and the values are what they should be.the bad locations when used in our robots code will always give data in a patern such as the one that i posted earlier (0,3,2,1,0,3,2,1…etc) and have no relation to any data given to the locations by any piece of our code **
I’m not sure what to make of your “pattern”. Maybe you can post your code (or a snippet.)
My best guess is that you’re saying that your program writes data to a scratchpad ram location, and when you read it back, the value is say a 0 (even though the value you had written was non-zero.) The next time you read it, the value is 3, and the next time it’s 2 and so forth. Does this describe your situation at all? (Or are you storing data in a sequence of cells, and when you read them back, these are the values you’re seeing in those cells?)
Some questions:
Some things to keep in mind:
*Originally posted by ChrisA *
**you have 62 scratchpad ram locations total in each bank.to sum this all up…
scratchpad ram is the physical memory area inside the robot controller where all your variable values are stored.**
A couple of problems here:
Also a couple more details you left out of your description:
oops i meant to put 64… ooh well
also forgot about the part that there is only one set of scratchpad ram which is what you have to use to share values with the other banks
anyways i would go with you on that programming error (which is what we thought it was at first) but when we took that var and changed its location (no there werent 2 vars using the same location, we did check that) it worked exactly how it was supposed to. weve had this happen at least 3 times and it definitly is the locations because weve tried different vars in a couple of those locations. like i said we spent like a couple hours debugging the code to find that that was the problem. id post a piece of code to show you that its fine but i dont have the code at my home computer.
the pattern as i remember it is always a pattern of numbers that sequentially run (0,3,2,1,0,3,2,1…) i think we had a pattern like 35,38,37,36…also but they dont really seem to relate to any values that we give it. (this is just one memory location which we are writing a value to then reading the value and finding it not to be the value we put there) an example, we were setting all of our drive wheels to the same value in the code…
(we changed it to look something like this for debuggin purposes)
PUT s_lf_wheel, 127
PUT s_rf_wheel, 127
PUT s_lb_wheel, 127
PUT s_rb_wheel, 127
upon reseting, after having downloading the new code to the rc, we found that the value for one of the wheels was running 0,3,2,1… while all the others (which had the same values) were stopped (at 127 as they should have been)
this whole thing has spooked us and we really dont know what to make of it. all we do know is that we cant use those locations otherwise well get some really really weird values.
maybe this will make some sense out of the issue for you (if you can understand what ive written here)
note: all scratchpad ram locations relating to pwms are set to 127 upon reset by a piece of our code
*Originally posted by ChrisA *
**…id post a piece of code to show you that its fine but i dont have the code at my home computer…
**
I’d still like to take a peek at the code when you get a chance. If you could extract a small piece of code that shows the failure, that would be ideal.
*Originally posted by gwross *
**
I vaguely remember seeing something on the Parallax BASIC Stamp discussion list about someone having problems with some bad memory locations in either the scratchpad RAM or in EEPROM. If I remember right, it was related to a particular rev mod of the BASIC Stamp2. **
I checked the BASIC Stamps mailing list archives to refresh my memory, and I see it is a problem with the BASIC Stamp 2P. (We have the BASIC Stamp 2SX.)
On the 2P, they have 126 bytes of scratchpad RAM, and the capability of accessing any of the EEPROM slots from a program running in any other slot. The 2P STORE command determines which EEPROM slot the READ and WRITE commands access.
The problem on the 2P is with the STORE command. It corrupts scratchpad locations 110 and 111 whenever it executes. The reporter stated that the STORE command always sets location 110 to 59 and 111 to 0.
So that’s not your problem.
*Originally posted by ChrisA *
**an example, we were setting all of our drive wheels to the same value in the code…
(we changed it to look something like this for debuggin purposes)
PUT s_lf_wheel, 127
PUT s_rf_wheel, 127
PUT s_lb_wheel, 127
PUT s_rb_wheel, 127
upon reseting, after having downloading the new code to the rc, we found that the value for one of the wheels was running 0,3,2,1… while all the others (which had the same values) were stopped (at 127 as they should have been)
**
So are you saying that you can execute a PUT to one of these bad locations, immediately do a GET, and the value has changed? Or do you have to go through the control loop before it gets changed?
How are s_lf_wheel, s_rf_wheel, s_lb_wheel and s_rb_wheel defined? They should be constants. If they are variables, could they be being corrupted?