Diagnosing compromised EPROM

J

John Chris

Senior Member
I have a misbehaving 28X2 that may have experienced excessive writing to certain bytes in eprom ...

Do we expect that the EPROM can be compromised a bit or byte at a time, blocks at a time ?

Can one byte be compromised, while an adjacent byte remain functional ?

Will the READ command return 0 when attempting to access a compromised bit, byte, or block of eprom?

Will executing a WRITE command on a compromised bit, byte, or block, affect any other part of the MCU ?

Any comments / suggestions are greatly appreciated.

Chris
 
Last edited by a moderator:
C

Chavaquiah

Senior Member
What symptoms are you seeing that make you suspect a bad EEPROM? That could be a cause but there might be other reasons...


Do we expect that the EPROM can be compromised a bit or byte at a time, blocks at a time ?

Writes happen one page (block) at a time but, of course, a few bits/bytes may start failing before their neighbours.


Can one byte be compromised, while an adjacent byte remain functional ?

In short, yes. It's not so much that a bit suddenly fails, it usually just starts loosing its hability to hold data.


Will the READ command return 0 when attempting to access a compromised bit, byte, or block of eprom?

Possible but not likely. 255 or a random value (maybe flipped bit) are more likely. If you're consistently getting a zero, I would suspect some other problem (logic/software?).


Will executing a WRITE command on a compromised bit, byte, or block, affect any other part of the MCU ?


Not likely unless something else in your program relies on the value written.
 
J

John Chris

Senior Member
Symptom:

A subroutine 'RequestDateAndTime' is executed. The user sends two ascii characters over RS-232, these are level-shifted by a MAX232, pass through an analog switch and are received by HSERIN. The ascii values are converted to a single 8-bit numeric value, and written to EPROM at the appropriate position within a time vector (6 consecutive elements) pointed to by an arbitrary pointer specifying the start point of the time vector. Alternatively, the ascii characters of each element are collected, converted and written to the RTC. The time is then read back from the RTC, written to EPROM, and displayed

A user enters '15' for the day part of the time vector, a '13' is read back from the RTC. See dialogue below where,

- 'Run (R) / Retrieve data (D) / Set time (T) / Clear memory (C):' is the main menu prompt of the system.

- input is echoed back and appears in []'s.

Dialogue:

Run (R) / Retrieve data (D) / Set time (T) / Clear memory (C): [t]

Reset real time clock
Current time: 00-JUL-2010 14:22:03
YY (09-99): [10]
MM (01-12): [5]
DD (01-31): [20]
hh (00-23): [10]
mm (00-59): [10]
Current time set to: 20-MAY-2010 10:10:00

Run (R) / Retrieve data (D) / Set time (T) / Clear memory (C):
Run (R) / Retrieve data (D) / Set time (T) / Clear memory (C):
Run (R) / Retrieve data (D) / Set time (T) / Clear memory (C): [t]

Reset real time clock
Current time: 20-MAY-2010 10:11:06
YY (09-99): [10]
MM (01-12): [7]
DD (01-31): [2]
hh (00-23): [14]
mm (00-59): [24]
Current time set to: 00-JUL-2010 14:24:00

Run (R) / Retrieve data (D) / Set time (T) / Clear memory (C): [t]

Reset real time clock
Current time: 00-JUL-2010 14:24:10
YY (09-99): [10]
MM (01-12): [7]
DD (01-31): [15]
hh (00-23): [10]
mm (00-59): [10]
Current time set to: 13-JUL-2010 10:10:00

Run (R) / Retrieve data (D) / Set time (T) / Clear memory (C):

I can describe this a little better if it is needed or if anyone is interested.

Chris
 
Last edited by a moderator:
M

MartinM57

Moderator
Got another PICAXE to put in circuit (briefly) to see if it all comes good?

I say briefly as you may have some coding error that is writing to the EEPROM very often and thus wearing it out quickly

Also, best keep things to one thread, or we'll all get confused...
 
M

MartinM57

Moderator
...and do YOU think that your code has written to the EEPROM around 1m times while you have been developing it?
 
B

BeanieBots

Moderator
If for just a minute we ignore datasheet spec and take a typical real life write frequency of ~1M, then your code can be expected to cause an EEPROM failure after about 10 days continuous use.

As mentioned in your other thread. Why do you write to EEPROM?
It's all held in variables. And there's plenty of memory in a 28X2.
 
J

John Chris

Senior Member
The reason I am not using variables is because I have developed a series of primitive functions for operating on time vectors. I have variables, say, 'arg1', 'arg2', and 'arg3' that can be loaded with pointers to various time vectors. It is a way of passing a time to a function that does not rely on set variables. For instance:

' Declare locations of time vectors in eprom
Symbol ptr_current_time = 10
Symbol ptr_start_time = 16
Symbol ptr_end_time = 22

LET arg1 = ptr_current_time
LET arg2 = ptr_start_time
LET arg3 = ptr_end_time
GOSUB SubtractTimes ' subtract time vector @ arg1 from that @ arg2 and store result @ arg3

LET arg3 = ptr_end_time
GOSUB TimeToScratchpad ' convert time vector to time string put in scratchpad. arg3 is 'TimeToScratchpad's argument

LET num_bytes = nb_timestring
LET strtpos = 0
GOSUB DisplayScratchpad
________
 
Last edited by a moderator:
J

John Chris

Senior Member
BeanieBots, Thanks for the suggested lifetime. I have been performing multi-day tests as I am developing for a service lifetime of a year. 10 days is consistent with some of the use that my hardware has been seeing.
 
Last edited by a moderator:
J

John Chris

Senior Member
MartinM57, Yes if I try a 'new' PICAXE or complete hardware assembly, all of the subroutines work very nicely. The symptom of the problem seems to develop with age.

Chris
 
Last edited by a moderator:
C

Chavaquiah

Senior Member
Funny you should have "scratchpad" used in many symbols, yet you went with EEPROM memory... :rolleyes:

May I draw your attention to the GET and PUT commands?
 
J

John Chris

Senior Member
I now understand that scratchpad RAM is ideal for frequent writes. EPROM, as I think I understand, is acceptable for frequent reads, or infrequent writes.
 
Last edited by a moderator:
D

Dippy

Moderator
Absolutely.
Use EEPROM with care.
And K series PICs tend to be a factor of 10 down on the number of EEPROM writes.
With a bit of skill and care (and if practical) you can splatter your writes around EEPROM thereby effectively increasing EEPROM write/erase lifetime.
 
M

MartinM57

Moderator
"Primitive Functions operating on time vectors" certainly get's bragging rights down the PICAXE pub (what name? "The Olde Conversion Wizarde" or "Wiz" for short?) ;) - I'd stick to scratchpad, as advised (might not be as big though)
 
D

Dippy

Moderator
Well I was so impressed that I didn't want to show my ignorance by asking - I guess that's the idea ;)

They have a Time Vector generator in the TARDIS - I'm not sure if it's similar in operation?

Beam me up Johnny :)
 
M

MartinM57

Moderator
So is time a vector or a scalar?

See you down the Wiz at 8 tonight for a deep and meaningful discussion, not doubt aided by a few pints of Butterbeer...
 
D

Dippy

Moderator
A knotty one.
Depends which physicist you speak to.
Once you get onto abstract Physics (the bit where you can prove anything and disprove nothing like String theory) then you can say what you want. If enough of you agree (because you are too scared to disagree)then any dissenter is a heretic.

We'll be onto man-induced Global warming next - can someone remember to plug that icelandic volcano please.

A 'deep and meaningful' in the pub? Oh please no..... I'm still suffering near-phone-the-Samaritans-experiences from World Cup bar-room experts who are too fat to run 50 metres.
 
B

BeanieBots

Moderator
I thought the football issue had been resolved. "they were tired".

@John Chris, put them out of their missery and explain what a "time vector" is.:confused:
(then I can pretend that I knew all along:D)
Is it an alarm clock? I'm always in a different "vector" when mine goes off!
 
You must log in or register to reply here.
Top