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 am not sure I understand, the device is code protected,
Rhanks
Per

 

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.

Hi John. Yes it is a graphical programing tool, sp I dont have access to the programming code, all symbols is made as a macro.
Yes the EEprom is dead, I cant write to it. I have tried to use the programming tool (MP lab) to write FF, but writing is failing, so yes it is dead.
I have been working with welding TIG machines, and they are really electrical noising, so I know a lot how to protect circuits, and also all 3 I have seen until now, has been working aprox. one year, and yes as you write, the rest og the micro is running OK. Thanks for helping regards Per

 

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.

Hi I only have this code files, but I can send all files in the library containing this device.
Yes I will do some aggressive test in the future.
Thanks
Per

 

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.

Hi and Thank: Yes the code is made from macros, and I can't get access to macross. But I have made a lot of project with Flip/flop counters and so on, whis value is stores in EEprom, and I have never seen one failure until now. I must day that all PIC are from the same production, can it be a bad production? Regards Per

 

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.

Hi No I have not added 20ms, because it is graphical programming, and code is made out of macros, Actum Solution must have taken care about this - I must contact them once again, the first time they have checked code, and the say that I have done no programming failure, so it must be something else ... I will contact them tomorrow. Thanks Per

 

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.

Hi No I have not added 20ms, because it is graphical programming, and code is made out of macros, Actum Solution must have taken care about this - I must contact them once again, the first time they have checked code, and the say that I have done no programming failure, so it must be something else ... I will contact them tomorrow. Thanks Per

 

Hi all again. I have been checking my old project.

BOR is disabled on the most of old project, but this project which fails
BOR is enabled

Could that be the problem?

I have read that BOR should be enabled, but now I am not sure?

Regards

Per

 

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.

I have never seen that fixed delay so stated. It is nowhere in the datasheet for the 16F690, but the erase/write cycle time is given as 5 ms (typical) in D123.

Can you provide a source for your claim that a 20-ms delay is needed after each EEPROM "write and read?"

John

 

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.

Micros from twenty years ago? May I know which ones?

 

Micros from twenty years ago? May I know which ones?

PIC16C57-04. It runs a little home-rolled RTOS to coordinate timing, billing, LED display mux, serial comms, button-based parameter editor/totals reader, I2C EEPROM and cycle stuff. Remaining codespace is 0.

 

PIC16C57-04. It runs a little home-rolled RTOS to coordinate timing, billing, LED display mux, serial comms, button-based parameter editor/totals reader, I2C EEPROM and cycle stuff. Remaining codespace is 0.

That's an oldie.
http://ww1.microchip.com/downloads/en/AppNotes/30384a.pdf

 

...billing...

Multi-user on a '57? Nice!

 

PIC16C57-04. It runs a little home-rolled RTOS to coordinate timing, billing, LED display mux, serial comms, button-based parameter editor/totals reader, I2C EEPROM and cycle stuff. Remaining codespace is 0.

Wow!

I started my MCP experience precisely with that one. Three chips in a merry go round with one always under UV, made for quick testing / debugging. The (hard printed) manuals, graciously sent to me from Arizona became my daily reading. Learnt a lot from the so much code in there. Hard as it was, the momentum was enough to write my own math library (16 bits inteegers).

Had to wait meeting the 16F84A to overcome my (unfounded) fear of interrupts! It was (is) an enjoyable journey. ¡Oh sí!

 

I have never seen that fixed delay so stated. It is nowhere in the datasheet for the 16F690, but the erase/write cycle time is given as 5 ms (typical) in D123.

Can you provide a source for your claim that a 20-ms delay is needed after each EEPROM "write and read?"

John

I use mikroC PRO PIC Compiler and in its help file "EEPROM Library" it is mentioned.

Requires EEPROM module.

Ensure minimum 20ms delay between successive use of routines EEPROM_Write and EEPROM_Read. Although PIC will write the correct value, EEPROM_Read might return an undefined result.

Maybe it is related with mikroC PRO PIC EEPROM Library but I have always used 20 ms delay after each eeprom write and read and I have never experienced any problems related to eeprom in my projects.

 

Hi all again. I have been checking my old project.
BOR is disabled on the most of old project, but this project which fails
BOR is enabled
Could that be the problem?
I have read that BOR should be enabled, but now I am not sure?
Regards
Per

BOR probably should be enabled. On at least one PIC (18F6622), the minimum Vdd for running at speed is higher than that needed to write the EEPROM. During power down, a slowly falling Vdd can make the processor lose its mind and clobber one byte of EEPROM data (where EEADDR was pointing). Ask me how I know this... For the '690, Vdd(min) is the same as the min Vdd to write the EE and that is where the brown out detector is set so that may not be an issue for that PIC.

But from your description i.e. the EE won't write any more, it sounds like you are either zapping it or wearing it out. AN1019 discusses EEPROM endurance. Try the Total Endurance Software which estimates how many cycles the EE will do. If all else fails, open a support ticket, get a phone case ID and give them a call. You might also get in touch with your local FAE. My FAE was the guy that fingered my problem with the 18F6622.

Good luck.

 

Maybe it is related with mikroC PRO PIC EEPROM Library but I have always used 20 ms delay after each eeprom write and read and I have never experienced any problems related to eeprom in my projects.

Thank you for providing that. I do not use C of any flavor.

The datasheet says to either poll the EEIF flag or enable its interrupt for internal EEPROM writes, which is what I do. Mikroe and PIC forums have many comments about using using fixed delays in the range from 2 ms to 30 ms; although, I did not find a single post by a Microchip representative that recommended a fixed time. It seems like a terrible waste of time to use a fixed delay that may be more than 10 times the amount needed.

John

 

Thank you for providing that. I do not use C of any flavor.

The datasheet says to either poll the EEIF flag or enable its interrupt for internal EEPROM writes, which is what I do. Mikroe and PIC forums have many comments about using using fixed delays in the range from 2 ms to 30 ms; although, I did not find a single post by a Microchip representative that recommended a fixed time. It seems like a terrible waste of time to use a fixed delay that may be more than 10 times the amount needed.

John

That 20 ms delay is required only if there are successive eeprom read or writes. If just reading/writing 1 byte then it is not needed.


@ph_elec

If you provide the schematic and explain the working of the device in detail then I might write a C Code for you for free. I will give you the C Code and .hex file. As the code size will be less than 4 KB it will easily compile in demo version of mikroC PRO PIC Compiler.

 

That 20 ms delay is required only if there are successive eeprom read or writes. If just reading/writing 1 byte then it is not needed.


@ph_elec

If you provide the schematic and explain the working of the device in detail then I might write a C Code for you for free. I will give you the C Code and .hex file. As the code size will be less than 4 KB it will easily compile in demo version of mikroC PRO PIC Compiler.

Thank You VERY MUCH! But i need to know what goes wrong, because I make many project - so I really have to know what goes wrong.
Actum Solution who has made made Realizer, have a C code builder, so that we can have the code in C, if You then will help finding the error I will be very glad But I have to ask Actum. I will do that later today Thanks Per

 

Thank You VERY MUCH! But i need to know what goes wrong, because I make many project - so I really have to know what goes wrong.
Actum Solution who has made made Realizer, have a C code builder, so that we can have the code in C, if You then will help finding the error I will be very glad But I have to ask Actum. I will do that later today Thanks Per

Yes, I can help with the Actum C Code. Mods doesn't allow to post email ID here. So, I will start a Conversation. You check your Private Message. I have provided my email there. You can email me the code if you can't post it here.

You can click the top right most icon on this page and select inbox and view the message and reply to that message.

@ph_elec

What do you mean by data corruption ? Do you mean that the data read from eeprom doesn't match with the data written i.e., counter value ? During EEPROM operation it is good to disable Interrupts.

It is good to turn off GIE bit.

 

Having C code to look at would be good, but something generated automatically by this Actum software might be very hard to read.

It occurred to me that maybe the EEPROM is getting hit by electrical effects. Apparently there is an on-chip charge pump which produces a voltage higher than Vdd, and perhaps that's vulnerable to a hostile environment where the rest of the chip is safer. But I'd still look very hard for anything that might be writing to the EEPROM when you don't expect it.

I wonder if there's any way that Microchip could figure out the nature of the damage to the EEPROM, if you sent them the damaged chips. But probably that's a kind of service that they won't do unless you pay them.