 |
 |
| View previous topic :: View next topic |
| Author |
Message |
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. |
|
|
SET
Joined: 15 Nov 2005
Posts: 161
Location: Glasgow, UK
|
|
| Posted: Fri Dec 07, 2007 10:27 am |
|
|
| Quote: | | 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? |
So you are saying that the PWM cycle update calls the EEPROM write function - this is probably what you would expect (so that system saves new PWM value). So do you mean that this call then caused EEPROM corruption? Can you get the system to echo back the values it is going to write to EEPROM? And then do an EEPROM read and echo that, to confirm it did write Ok?
So you would get something like:
PWM update command -> PWM changes -> EEPROM is updated, echo'ed back -> EEPROM is read back |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
