Hi I am using this Up, and store a counter value in eeprom. Now after 1 year 3 pieces out of 100 pieces, has come back, and the eeprom aria is
total corrupted, and I caan use it anymore. Not only the adress which I use is corrupted, but the whole aria is written with currupt data. I don't know what I am doing wrong. Here are my configurations bit:

FOSC: INTOSCIO oscillator :I/O Function on RA4/OSC2/CLKPIN, I/O function on RA5/OSC1/CLKIN
Watchdog timer: WDT enabled
Power-up timer: PWRT enabled
MCLR: MCLR pin function as digital input, MCLR internally tied to VDD
CP: Code protection enabled
CPD: Data code protection is enabled
BOREN: Brown-out Reset Selection bit: BOR enabled
IESO: Internal External Switchover bits: Disabled
FCMEN: Fail safe clock monitor is disabled.

That it. What can I have done wrong. I am not 100% sure about those configuratios bits.
I am using Realizer Gold from Actum Solutions. It a grafic programming tools, so I have only assampler code, which have been
checked at Actum solutions, and they says that program code is OK.
So I really need so find out what goes wrong.
Thank You very much for reading this
Per Haastrup
Denmark

 

How often are you erasing and writing to the eeprom. That answer will be in the program, not the configuration.

John

 

Hi John, maybe 3-4 times for one year

 

Is the EEPROM permanently damaged (i.e. you can't write anything to it, or what you write isn't properly readable) or was there just corrupt data in it when you received the chips after a year of use?

You say you're storing a "counter value" in EEPROM but you're not saying how often it gets stored, or what triggers a write operation. I'd be suspicious that the program is actually writing to EEPROM more often than you think it is. Actually we all know that these chips have an EEPROM with limited life, but I don't know how it fails if you exceed its lifetime. What would happen when it fails?

 

Are you sure that the program doesn't write to the EEPROM even when the value hasn't changed?

 

Hi John, Yes Actum Solutions say that counter value only is stored in EEprom when it has been changed.
In datasheet Microchip sayes 1,000,000 write endnurace.

I have just found out, taht I can fill eeprom area with ff, and the it is possibel to use PIC16F690 as normal again,
so it is not dead.

Thanks

 

Hi again.

No I was to optimisttic :-( I can erase chip, but I can't write ti EEprom flash,
it's dead :-(

Sorry .....

Regards
Per

 

Can you show the code for how or when the counter is changed and written? How is write controlled? That is, is it on every change or only at the end of some process? If it is used as a regular counter do you at anytime have a destination of the counter (i.e., f or 1) in the code?

John

 

Hi John.
I can show it graphic, and in a ASM og INC file.
As I have made the counter, it only the value of the counter and it goes from 0-60, and
then I use the value as a timer value.
I am not sure I understand this " If it is used as a regular counter do you at anytime have a destination of the counter (i.e., f or 1) in the code?"

Thank You very muck
Per

 

When you increment or decrement the counter and the destination of that operation is the counter register (i.e,. f or 1) the counter value changes.

Probably best if you show the code. Don't be shy because it is in Assembly.

John

 

I have tried to upload some more files, but files does not have legal name. Is it possibel to mail?
Thanks
ASM file uploaded.

Thank You
Per

 

I have uploaded some more files in this Bras.zip.

Thanks

Regards

Per _ Here are the graphic diagram. The counter with M is a memory counter, and it is this value which a stores in eeprom. As You can see I only count up, and only in "Setupp mode" SS is the start button, and it must be hold for 5 sec, and then the F/F is triggered, and gives through the AND gate permission to count op the counter. We push fx 10 times, and the counter has value 10, then this value is clocked out on a LED, så that the time can be checked, if time is OK, the we switch off the unit, and after few second we switch on again. I have read some places on Google, that there can be problem when switching off when writing, but BOR is enabled, and we are push the swith, so counter should be finish writing to eeprom at this time. This was a long text ..... ThankYou Regards Per - I will be back tomorrow

 

chk-if-ok ? 3.2 EECON1 and EECON2 Registers -- only if such also apply to PIC16F690 (i donno that chip)
chk-if-ok ? 5.0 CODE PROTECTION
chk-if-ok ? voltages on work site (of opreation) -- insist UPS or other conditioned feed while necessary

 

I can't make much out of the files. Most of us use a C compiler for working with PIC processors, but this seems to be done with a graphical input in the form of a flow chart. Is that what you're showing us?

If you're saying that the EEPROM is definitely dead, then I'll repeat that I think it must have been getting written too many times. The only other thing I can think of is that there might be high-powered electrical fields affecting the chip, but I'd be surprised to hear that there may have been electrical damage which destroyed the EEPROM and left the rest of the chip functional.

 

I have uploaded some more files in this Bras.zip.

I thought they had hook-and-eye fasteners; not zips! .

 

but I don't know how it fails if you exceed its lifetime.

They will either fail to program due to excessive charge trapping in the oxide, be "stuck at", or be leaky.

 

he only other thing I can think of is that there might be high-powered electrical fields affecting the chip

Fowler Nordheim Tunneling occurs at an electric field strength on the order of 10MV/cm. At lower field strengths, the affect would be non-destructive and the device would retain the ability to be programmed.

 

The file you have posted doesn't contain any EEPROM write code, not that I can find. Can you post only your EEPROM writing code?

Also, get a pin, declare it as output, drive it high before you write EEPROM, drive it low afterwards. Connect it to a pulse counter. In a couple of days, see if you have any pulses. Do some regular activity with your device and see if any of it produces pulses on that pin.

 

The file you have posted doesn't contain any EEPROM write code, not that I can find. Can you post only your EEPROM writing code?
Also, get a pin, declare it as output, drive it high before you write EEPROM, drive it low afterwards. Connect it to a pulse counter. In a couple of days, see if you have any pulses. Do some regular activity with your device and see if any of it produces pulses on that pin.

That's what I would do, too. There is what appears to be an EEPROM library in the includes (p16ceep.inc) but the code flow seems to be generated by macros so hard to tell what's going on.

FWIW:
__CONFIG B'0000001100001100' evaluates to the config parameters you indicated in the first post.

We see EE failures from write endurance issues in timers we used to build. Over 20+ years in service, we wear out the EE. Like yours, it will read but won't write. A new EE fixes it.

During development of the timer itself, we also found that routing an un-suppressed high-tension lead (spark igniter) adjacent to the timer would cause the EE to fail. There is a little charge pump in the 24C01 that makes Vpp - it got toasted by the spike and no more writes.

That said, I don't know if the internal EE in the '690 behaves the same.

100K is the minimum guaranteed number of writes. 1E6 is typical.

See the note on parameter 35 in the Electrical Characteristics regarding Vdd decoupling and brownout detector to ensure that the PIC won't clobber EE data. That wouldn't account for a broken EE like it looks like you have but thought I'd point it out.

Good luck.

 

How do you say that data in eeprom is correpted ? maybe EEPROM read is not working properly. Have you added 20 ms delay after each eeprom write and read ? This is a must.