| View previous topic :: View next topic |
| Author |
Message |
ScottRHinson
Guest
|
| EEPROM gets corrupted in 18F4680 |
 Posted: Wed Dec 05, 2007 2:32 pm |
 |
|
All,
I have a board that runs a 500W PWM based power supply using a PIC18F4680 processor. Occasionally, without rhyme or reason the calibration constants I have stored in EEPROM are overwritten and then the processor resets.
I have gone to the length to write the constants in twice, with checksums...whichever set matches the checksum is used..and if the other doesn't match the checksum it is corrected. A simple error detection and correction if you will.
I'm still having issues with the EEPROM. Anyone see EEPROM get corrupted during program execution, without a good reason....before? If so what did you do to fix it?
Thanks,
Scott |
|
 |
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Wed Dec 05, 2007 2:56 pm |
|
|
1. How many hours does the PIC have to run before this error occurs ?
2. Does the error occur only if the power has been cycled ?
Are you writing to the data eeprom just after the power switch
has been turned off, when the Vdd voltage to the PIC is falling ?
3. What method are you using to show that it's failing ?
Are you periodically calling printf to display the eeprom contents ?
4. What's the Vdd voltage on the PIC ? What's the oscillator frequency ?
Are you using the PLL ?
5. Are you operating the PIC out of spec in any way ? Such as using
the regular voltage version when the LF version should be used ?
6. What's your compiler version ? |
|
|
ScottRHinson
Guest
|
|
| Posted: Wed Dec 05, 2007 3:15 pm |
|
|
Wow, thanks for the quick response....
1. Optimally, more than 5000.
2. No, the error occurs during operation, after power has been on for a while. Sometimes as quickly as a couple of days.
3. Yes, that is correct.
4. The Vdd is 5.0VDC, I'm using the internal 8MHz oscillator multipled up to 32MHz.
5. I don't believe that I am, but I will re-check.
6. PCH-C 3.215
| PCM programmer wrote: | 1. How many hours does the PIC have to run before this error occurs ?
2. Does the error occur only if the power has been cycled ?
Are you writing to the data eeprom just after the power switch
has been turned off, when the Vdd voltage to the PIC is falling ?
3. What method are you using to show that it's failing ?
Are you periodically calling printf to display the eeprom contents ?
4. What's the Vdd voltage on the PIC ? What's the oscillator frequency ?
Are you using the PLL ?
5. Are you operating the PIC out of spec in any way ? Such as using
the regular voltage version when the LF version should be used ?
6. What's your compiler version ? |
|
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Wed Dec 05, 2007 3:55 pm |
|
|
1. When are the calibration constants programmed into the PIC ?
Are they put in at the factory, before the unit is shipped to the customer ?
If so, is that the only time they are ever programmed ?
2. Are the calibration constants programmed into the PIC with a
programmer (such as ICD2, or Promate, etc.) ?
Or, are they programmed by using the write_eeprom() function ? |
|
|
Guest
|
|
| Posted: Wed Dec 05, 2007 4:09 pm |
|
|
They are programmed by the customer through a serial interface, which activates the wrtie_eeprom() function.
The function seems a bit odd in that it appears that it makes up to three attempts to write. I did not do the original programming so I can't figure out why there are three write attempts.
Thank you again for your prompt response and questions!
| PCM programmer wrote: | 1. When are the calibration constants programmed into the PIC ?
Are they put in at the factory, before the unit is shipped to the customer ?
If so, is that the only time they are ever programmed ?
2. Are the calibration constants programmed into the PIC with a
programmer (such as ICD2, or Promate, etc.) ?
Or, are they programmed by using the write_eeprom() function ? |
|
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Wed Dec 05, 2007 4:20 pm |
|
|
| Quote: | | They are programmed by the customer through a serial interface, which activates the wrtie_eeprom() function. |
Are you able to duplicate this problem in your lab ? |
|
|
ScottRHinson
Guest
|
| EEPROM Resets... |
| Posted: Wed Dec 05, 2007 4:30 pm |
|
|
I have been able to duplicate it...but only occasionally. It seems to happen on starting or stopping the PWM, but this isn't always the case.
I can't seem to find a direct cause. I've been monitoring supply voltage, which is stable, and the MCLR pin which is okay as well.
What I had done is have the processor default to the flash values of the cal constants to revert to a "limp" mode. They originally thought this would be good enough.....but now they are not convinced.
Scott |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Wed Dec 05, 2007 4:40 pm |
|
|
| Quote: | | It seems to happen on starting or stopping the PWM, but this isn't always the case. |
Does the PWM run a motor that uses high current ? Is the ground and/or
power path for the motor driver circuit on the same PCB traces (tracks)
as the PIC ?
Does the board layout (or wiring) look like this:
| Code: |
+V ---------------->Motor driver circuit
|
PIC
|
Gnd --------------->Motor driver circuit
|
If so, change it to this.
Connect the high current wires for the motor driver directly to the power
supply or voltage regulator, with their own separate tracks or wires.
| Code: |
+V ---------------> Motor driver circuit
|
---------
|
PIC
|
---------
|
Gnd ---------------> Motor driver circuit
|
|
|
|
ScottRHinson
Guest
|
|
| Posted: Wed Dec 05, 2007 5:35 pm |
|
|
It actually is a battery charger, and I've set the wiring up to look like your second drawing. I typically have been using differential probes to look at the 5V supply.
| PCM programmer wrote: | | Quote: | | It seems to happen on starting or stopping the PWM, but this isn't always the case. |
Does the PWM run a motor that uses high current ? Is the ground and/or
power path for the motor driver circuit on the same PCB traces (tracks)
as the PIC ?
Does the board layout (or wiring) look like this:
| Code: |
+V ---------------->Motor driver circuit
|
PIC
|
Gnd --------------->Motor driver circuit
|
If so, change it to this.
Connect the high current wires for the motor driver directly to the power
supply or voltage regulator, with their own separate tracks or wires.
| Code: |
+V ---------------> Motor driver circuit
|
---------
|
PIC
|
---------
|
Gnd ---------------> Motor driver circuit
|
|
|
|
|
Ken Johnson
Joined: 23 Mar 2006
Posts: 197
Location: Lewisburg, WV
|
|
| Posted: Thu Dec 06, 2007 8:04 am |
|
|
How robust is the serial comm error checking ?
Is it possible that pwm induced noise on the serial line causes a call to write_eeprom() ?
| Quote: |
They are programmed by the customer through a serial interface, which activates the wrtie_eeprom() function.
|
Ken |
|
|
Guest
|
|
| Posted: Thu Dec 06, 2007 8:45 am |
|
|
| Ken Johnson wrote: | How robust is the serial comm error checking ?
Is it possible that pwm induced noise on the serial line causes a call to write_eeprom() ?
| Quote: |
They are programmed by the customer through a serial interface, which activates the wrtie_eeprom() function.
|
Ken |
Between the checksum and formatting requirements the odds of an accidental call...are very...very near zero.
Does anyone know why the previous programmer might have called up to three successive EEPROM writes? |
|
|
treitmey
Joined: 23 Jan 2004
Posts: 1094
Location: Appleton,WI USA
|
|
| Posted: Thu Dec 06, 2007 9:48 am |
|
|
Not 3 writes. It is common to read eprom and write ONLY if new value is different. Then perhaps he reads it to verify a good write.
1.read 2.write if changed 3. verify.
Anyway. Can you test this with a I2C FRAM. My gut is thinking that it has to do with the long time for eprom write. perhaps you get irq's for the pwm in there, and that blows it up(tho it shouldn't).
Any chance of a FRAM? just to narrow it down a little.
Last edited by treitmey on Thu Dec 06, 2007 12:53 pm; edited 1 time in total |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Thu Dec 06, 2007 11:54 am |
|
|
The reason for doing three writes would be that he's afraid that the
eeprom is not really being written. Does the code do it like this,
with the same address and data ?
| Code: |
write_eeprom(address, data);
write_eeprom(address, data);
write_eeprom(address, data);
|
Or is it more like this, and with some error handling if the write
doesn't work after three attempts:
| Code: | for(i = 0; i < 3; i++)
{
write_eeprom(address, data);
temp = read_eeprom(address);
if(temp == data) // Verify that it was written OK
break;
}
|
Can you confirm that you're using the internal data eeprom inside
the PIC and you're not using an external eeprom chip ?
Also, are you currently testing for the occurrence of the problem after
doing the wiring changes ? Or are you waiting for new suggestions
from us ? |
|
|
ScottRHinson
Guest
|
| EEPROM problems... |
| Posted: Thu Dec 06, 2007 1:46 pm |
|
|
| PCM programmer wrote: | The reason for doing three writes would be that he's afraid that the
eeprom is not really being written. Does the code do it like this,
with the same address and data ?
| Code: |
write_eeprom(address, data);
write_eeprom(address, data);
write_eeprom(address, data);
|
Or is it more like this, and with some error handling if the write
doesn't work after three attempts:
| Code: | for(i = 0; i < 3; i++)
{
write_eeprom(address, data);
temp = read_eeprom(address);
if(temp == data) // Verify that it was written OK
break;
}
|
Can you confirm that you're using the internal data eeprom inside
the PIC and you're not using an external eeprom chip ?
Also, are you currently testing for the occurrence of the problem after
doing the wiring changes ? Or are you waiting for new suggestions
from us ? |
The code looks more like your second example. (I wish I could post code...but I have several NDAs that would probably prevent it.)
I originally had the system wired like your second example, so I'm currently waiting for any inspiration that anyone can provide. I'm also trying to nail down an exact, repeatable cause.
This is indeed the internal EEPROM...I did the hardware design, and now I'm getting pulled into the software since the embedded programmer left.
I've managed to get one instance of the EEPROM corruption since yesterday. I had added some test code to tell me if the processor ever entered the EEPROM write functions. I let the system run for several hours with no instances...power down, and up 40 times. I had no data loss.
Next I put in some test code that would print some status registers every time the main loop executed a PWM duty cycle update to see the status of the system at that time. Within a few minutes of adding that piece of test code I had one instance of the EEPROM write function called. Is there any way the two could be related? The customer is using a RS-485 interface to communicate and log data from the microcontroller, meaning there are constant read/writes via serial comms. Am I just barking up the wrong tree because of very small sample set?
Scott |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Thu Dec 06, 2007 2:58 pm |
|
|
You need to "push" the system to make it generate the eeprom errors
more often.
1. To see if the PWM duty cycle change is causing the problem, try
sending these commands at a much greater rate than normal.
For example, if the customer changes the PWM duty cycle every
minute, then try changing it every 5 seconds, or every second.
You could write an external program to send the RS485 commands
at a much higher rate than normal (this could be done by another PIC)
or you could modify the main PIC's program to do this.
2. If the customer does a small change in the duty cycle, try making
it be a much larger change. If the duty cycle change is causing
spikes on the Vdd or Gnd on the PIC, this technique may cause the
problem to occur much more often.
Questions about the board layout:
1. Does it have power and ground planes ? (i.e., is it a 4-layer board ?)
2. Do you have a tantalum capacitor on the input power connection to
the board, or on the output of the regulator.
3. Do you have 100 nF (0.1 uF) ceramic capacitors on all the Vdd pins
of the PIC ?
Other things to try:
1. You said the power supply is a battery charger. Normally, I don't think
of those as having a very clean output. Try using a regulated power
supply.
2. Try running the PIC without the PLL. Run it either at 8 MHz, or change
the crystal to 20 MHz and run it in HS mode. |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
