EEPROM protection and PIC18F4550

[neo19]

Hy,

I'm working with PIC18F4550, PCWH compiler 5.030 and CCSLOAD V5.022.

I have a question about EEPROM :

Do you know if it's possible to protect the internal EEPROM? I saw that it's possible with CCSLOAD but I don't want to do it with the programmer.

On my boards I use USB connection for changing some parameters.
But after changing parameters, I would like to protect the EEPROM to be sure that it will not be erased by a noise, EMC,...

But sometimes I would like to unprotect the EEPROM to modify parameters.

Is it possible or not using USB commands?

Thanks in advance for your help,
Best regards
Fabrice

[PCM programmer]

Look at the write_configuration_memory() function in the CCS manual.
The endurance for this memory can be as little as 10K cycles, per the
18F4550 data sheet.

[Ttelmah]

Beware also. If anything in this goes wrong, you can leave the chip in an inoperable state. Honestly much more dangerous than doing something simpler like having a checksum and duplicate on the EEPROM, so you can recover if a byte gets incorrectly changed.

[temtronic]

It's far more likely that RAM will be corrupted before EEPROM from 'noise'.
You can minimize problems by adding filter caps, chokes, MOVs, sparkgaps at PCB external connections, HF bypass caps at PIC (see datasheet), and having a well designed power supply. Also use wide, thick traces for power on PCB, proper ground plane too.
I've had PIC products survive nearby lightning strikes that took out PCs and phone systems. Back then (25 years ago) I did NOT want to service equipment at 2AM in the dead of winter so I 'over engineered' the product, which is STILL running today.


Jay

[RF_Developer]

What exactly is the problem you are trying to solve? You mention concerns about noise, but are you seeing corruption inactual use? Are you worried about malicious alterign of data? What exactly are you worried about?

EEPROM is difficult to write to. It requires a relatively high voltage and a ms of time. A write is in two parts, first an erase of a byte of group of bytes then the new data is written. It is very, very difficult for all that to "just" happen. So noise is really not an issue. Also with PICs there is already an inadvertant write prevention mechanism built into the hardware. Code must send a special sequence to unlock the EEPROM and enable writing before actully writing the data. This is pretty much what I think you are describing. The CCS C compiler routines do all that for you so you may not be aware that its even done at all.

Most of my projects use EEPROM and I've never had any EEPROM content corruption. I've had incomplete EEPROM writes, such as when writing when power is going down, but never previously good data being corrupted.

Protecting the EEPROM contents from being read for reverse engineering purposes is a whole other matter.

So, what, exactly is the problem you are seeing? Or is it just a vague fear or feeling of unease that corruption might occur even though you have no evidence of it?

[neo19]

Thanks for your answers.

I use PIC18F4550 in 4 different types of boards inside our equipment. I use the internal EEPROM to save some parameters.

One type of board is a fan board which change the fan's speed in function of the internals temperatures.

My problem is that sometimes I lose some data inside the internal EEPROM. Not at the power ON of the board but during operation.

This board controls 2 fans (60W each) with PWM and check the sensor speed.

A power supply is connected to the board and fans are directly connected to the board. So there were lots of noise on my board.
I changed the wiring and now the board as is own power supply and the fans have their owns power supply.
Now the noise is reduced and not dependent of the fan's speed.

I will see in the time if the problem is solved or not.

Thanks

Fabrice

[Ttelmah]

I'd suspect you might be getting a supply glitch during the actual write cycle. This can result in other cells being corrupted (not only on the PIC EEPROM's but on EEPROM's in general). Add a zero sum to the data. So each variable stores it's value and an extra byte to make the result sum to zero. Include this in the data you save. Then when you complete the save, read back and verify that the sum is correct. This way (unlike a full checksum), the extra byte only needs to be written as often as the data itself. If you are getting such a glitch, a protection won't help, since this will have to be turned off during the write...