BS2e eeprom "glitches"

jmalaysia

I am using a BS2e.· It seems that data is not always properly retrieved from eeprom storage.

This is partial code,· for simplicity...

First,· I clear the eeprom using:

FOR blank=0 to 800
WRITE blank, 0
NEXT

Later I write to the eeprom using:

FOR move=0 to 800 STEP 5
WRITE move, direction, speed,· timer,· word time
NEXT

In a later section of the program,· I read the·data using:

FOR move=0 to 800 STEP 5
READ move, direction, speed, timer,· word time
NEXT

direction,· speed,· and timer are all byte variables.

move and time are word variables.

I have plenty of eeprom space available (nearly 1k free).

As the program reads the data,· it looks for VAR time to be zero.· If it sees time=0 then it breaks out of the READ loop.

ANYWAY...· 99% of the time the program runs flawlessly.· 1% of the time it seems to READ a 0 and abort prematurely.

Has anyone experienced problems such as this?· Is a checksum needed and does anyone have a good one to suggest?

·

Bruce Bates

jmalasya -

You're writing 6 BYTES (time is two BYTES long) and incrementing by FIVE! Is it my math or yours that's off?

Regards,

Bruce Bates

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Veni, Vidi, Velcro! - I came, I saw, I stuck around!

jmalaysia

Ha!· I keep thinking that myself,· but·MOVE isn't writen-· it's the location.· So I think its correct:· direction,· speed,· timer = 3 bytes plus time (2 bytes) = 5 total.

Mike Green

How often do you go through this clear / write / read cycle? Remember that EEPROMs are good for only 1,000,000 erase/write cycles. The 16K byte EEPROMs used in the BS2e are organized in 64 byte pages where a write to any location in the page causes the whole page to be written as a block. Sequential writes accumulate for the page. If you do a sequential erase, then a sequential write, that's 128 writes to the involved page. The page will wear out after around 10,000 of those passes. These tend to wear out by being unable to write new data. If you do a pass every minute, that's 1500 per day. It would only take a week to start to see problems.

If this sounds likely, you may be seeing intermittent bit write failures where part of a byte writes successfully, but one or two bits do not. Depending on the data being written, you may read a zero value instead.

Unsoundcode

Where does the variable time come from, have you ruled out the possibility that time actually is being written as zero.

Perhaps instead of breaking out of the READ you could run it a few times displaying all 160 samples each time, it might give you an indication of bad memory sectors or invalid data.

Looking at Mikes explanation it's possible to wear out EEPROM memory faster than one might think, you may want to consider an alternative media to write to, maybe the Parallax logger.

Jeff T.

Tracy Allen

Mike, I don't agree about the 64 byte page being written each time. This is eeprom, not flash, and it has true random byte addressing. It does have the capability to be written in page mode, where it receives 64 bytes into a buffer and then the whole buffer is written at once, but that mode is not used in the Stamp WRITE command.

That does not contradict the possibility that the errors jmalaysia is seeing are due to wear-out. A checksum is a good idea. Simply store one more byte, with the sum (//256) of the other 5 bytes. Since there is a lot of eeprom available, in this kind of situation, I like to set up a large circular buffer with a pointer to the start of the current run, and an offset pointer to the next available location for the next record. At the start of a new run, the start pointer moves up to the position of next available. The two pointers chase one another around the large circular buffer and the wear on the eeprom is leveled out. This scheme is much easier to implement if there is a place like clock ram, battery backed, to store the pointers.

Jeff has a point too, what about the variable time. And what about the possibility that the pointer gets bumped up more than expected and skips a record during the recording, leaving a hole?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com

Mike Green

Tracy,
It's hard to tell from the EEPROM specs just what they actually do with writes. I did check a different parallel EEPROM that Atmel makes. This one has a 128 byte page and the spec says that bytes not changed by the paged write are not cycled in the memory array. I assume that they do their serial EEPROMs the same way. Still, jmalaysia's program would only take 64 weeks to wear out the EEPROM with a once per minute cycle. That's only a bit more than a year at that rate. Atmel, on the other hand, specifies their durability to be for at least 100,000 cycles which would reduce things by a factor of 10.

jmalaysia

Thanks for all the responses. I'll try to answer the questions. The variable TIME comes from a loop which records the time a button is pressed. It is unlikely that it is written incorrectly as it will read properly many times then (without rewriting or clearing) it will see a zero and abort. Running it again immediately after will usually result in a good run as well, so I think the data is there and correct, which is why I think it is a read problem.

As for the frequency I clear, read, and write, it is a manual function, only done on command, so for practical use it will probably only be done a few hundred times ever. What this thing does is record motor movements that are input via a user with a remote control, then play back the movements on command. A switch is used to initiate eeprom erasure, after which it writes the desired "moves."

As for looking for bad data, I have set this thing up and let it cycle continuously for hours and it has never burped once while I was monitoring it. Kinda like a kid- always good when you are watching it, but walk away BAM they start cutting up.

allanlane5

You could easily put a check in the 'WRITE' loop, and output a message if it DOES get a 'time' value of zero...

Edit: Or at the very least, if it DOES get a time of 'zero', set 'time' again (re-read the button press, in other words).· This almost (but not quite) sounds like a time-out of some kind resulting in a 'time' of 'zero'.

Tracy Allen

Mike, good point. They don't reveal on the specs what goes on under the hood. But here is what WIKI says about it:

<<Flash memory is a later form of EEPROM. In the industry, there is a convention to reserve the term EEPROM to byte-wise writeable memories compared to block-wise writable flash memories. EEPROM takes more die area than flash memory for the same capacity because each cell usually needs both a read, write and erase transistor, while in flash memory the erase circuits are shared by large blocks of cells (often 512

Mike Green

The general rule on problems like this one is that it's very very rarely some kind of hardware "glitch" in established hardware.· Overwhelmingly, these are programming errors or due to erroneous assumptions (like some kind of timeout) or even electrical noise or "cold solder joints" in your setup.· This is not to say that problems never occur in hardware that you've bought, but first you have to eliminate "glitches" in your own stuff with instrumentation (debug statements, scopes, etc.) since that's where such problems usually arise.

Tracy Allen

jmalaysia,

If the routine doing the writing has a definite end point, it could write an end of file marker into the next free record. Say $ffff in the time field. That would be distinguished easily from a 0 and would take a specific program action to create.

Or, when the acquistion routine ends, have it immediately write the value of its end pointer to an address that the read routine can retrieve for its end count.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com

jmalaysia

Not for a second would I say my programming is NOT the cause, or that there is not some external cause. My goal by posting was to see if anyone has ever had a similar problem or if anyone has had success when doing a similar operation. No, there is no real time clock. I certainly would not expect any microprocessor to have trouble keeping up with memory/locations but I have LOTS of experience with everything I am dealing with except the basic stamp. I'm just trying to eliminate it as the cause on the forum rather than sitting out in the cold in a horse barn with cows bumping into me while balancing a laptop for debugging. If I sound a little cranky I apologize... just got home from work and yes, I am heading out to debug the thing shortly, cows and all! If I learn anything worthwhile, I'll let you guys know.

Thanks!

Tracy Allen

I feel your pain. I've had to set up and troubleshoot equipment in trying circumstances. Those cows! They can chew cables and knock over the equipment, but they are not know to insert zeros in files!

By the way, just how cold is it in the horse barn? The BS2e can have trouble at low temperatures, but the temperature would have to drop below -20 Celsius, below zero Fahrenheit, for that to happen.

I have a lot of experience using the Stamps for data logging, but mostly I have been using an external eeprom or flash to log the data, not the Stamp's own eeprom. I don't recall any problem similar to what you are describing. Not to say that there have never been problems! Most problems I have had trace back to programming, or power supply or misconnection issues, not to the Stamp itself.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com

jmalaysia

Oh it's not really THAT cold...· only about 35,· but that's cold to Texans.· Not a lot was learned tonight,· except that for the most part the program·aborted with a valid read debug,· meaning it read the eeprom and did NOT see a zero but aborted anyway.· No incidents with the cows or horses to report tonight!· I brought it home tonight to see if I can learn more,· but it never seems to want to screw up here.· Actually,· it's just much harder to tell if it screws up or not.· The final product runs a flag back and forth (horizontally) at different speeds & distances up to 100'.· I can't really replicate that in my house.

jmalaysia

Update: Well *maybe* I've got it whooped...

I'm switching a few relays. One controls speed, one controls direction, and another one actually RUNS the motor. Speed is very low current. Direction and Run are somewhat high current (5 amps/90vdc). As I was programming, I considered the BS2 "instantaneous" in relation to relays, and therefore did not organize the switching order of the relays. For example, I might have engaged the RUN relay, then the speed relay, then the direction relay in sequential program lines. In doing so, it is possible that I generated quite a bit of noise if the run relay was engaged, then suddenly the field was reversed by the direction relay. Maybe that noise was messing with the stamp. At least I'm hoping it was.