18F4550 EEPROM not Programming or staying Programmed

Tom-H-PIC · Joined: 08 Sep 2003 Posts: 105 Location: New Castle, DE

Hello All
We have a product that is test equipment.
We have ~400 of these units.
We use about 150 units at a time on a system.
The units are shipped all over the world for this testing.
We built them back in 2005 and 2006.
So the software started at rev - on compiler 3.249 and now todays is rev G on compiler 4.129.

For calibration connection the unit uses CCS CDC USB stack.
When the unit is calibrated the software stores the calibration numbers in EEPROM.
Then recalls and loads them on boot.

The problem is that we calibrate the units and during this the software stores the calibration data in the EEPROM or that is what is to do.

We do a burn in period to test the unit after calibration.
And then recheck the units just before shipping.

This is when the issues come up!
Some of the units boot up like they have never been calibrated at all (ON cal data in eeprom).
Some times this can happen in the burn period if the unit is shut down and restarted.

And it is not all units, but it is not all the same units at the same time either.

I have looked at the ASM files 3.249 and 4.129 and yes they are not the same but there not too far apart. I think that that big of jump in compilers it is going to be hard to see if the asm is the same.

So I don’t know what to look for.
The only though I have is that an interrupt is screwing up the eeprom write sub.

Anyone have any ideas?

Thanks All
Tom

PCM programmer · Joined: 06 Sep 2003 Posts: 21708

temtronic · Posted: Wed Feb 08, 2012 9:12 pm

Off the top of my head...

timing( EEPROM cycle time) might be off ??

EEPROM address ? Is it always the same ?

Does it only affect v4.129 units?

Are they all the same Microchip datecode/production runs.

Any change in the firmware (ISR left enabled, no delay after writing the eeprom ??)

I'll assume you're using an external xtal, proper caps ??

running out of straws.....but will think more about it !

gpsmikey · Joined: 16 Nov 2010 Posts: 588 Location: Kirkland, WA

the old gray hairs ain't what they used to be ... wasn't there something a year or so back where someone was having some issue with chips on a board that would work fine but then sometimes they "forgot" calibration data or something ? Seems to me it was related to some reset timing or something. Wish I could remember more about it - I just remember it had something to do with reset timing or something.

mikey
_________________
mikey
-- you can't have too many gadgets or too much disk space !
old engineering saying: 1+1 = 3 for sufficiently large values of 1 or small values of 3

Tom-H-PIC · Joined: 08 Sep 2003 Posts: 105 Location: New Castle, DE

The boards are not new. There are the same boards from 05 and 06 and I think we built some in 07 all so.
We are the end user of the units so one of our people is with the units with the customer.
This is a list of compilers that have been used on these units.
3.249
4.104
4.119
4.129

The units have had the issue with all compilers.

No the 18F4550 are not the same date codes, the time frames would not fit for that.
There was a min of three different orders of PIC18F4550.

The software has changed some but no new ISR.
But there is no delay after the eeprom_write.
CCS manual does not show that I need to delay after the write.

Yes external xtal and caps 20Mhz setup for USB.

No issues with the USB or the clock that I know of.

Tom

Tom-H-PIC · Joined: 08 Sep 2003 Posts: 105 Location: New Castle, DE

I forgot
No it is not the same address all the time it is random address in the EEPROM.

Tom

PCM programmer · Joined: 06 Sep 2003 Posts: 21708

See this thread and the links in it:
http://www.ccsinfo.com/forum/viewtopic.php?t=37757

temtronic · Posted: Thu Feb 09, 2012 6:41 am

Well...you took away most of what I was thinking but the link PCM gave does suggest a 'marginal power supply' could be the culprit.
The fact that it's a 'common' problem, not tied to a certian chip or compiler version means it's elsewhere.

Even though the PIC is a low power device,LEDS,relays and other peripherals can cause 'huge' power surges could drop the VDD to less than 'correct'. One scenario is turning on an LED when the EEPROM cycle is issued.Another is sending serial data via MAX232 chip.

A bench test recording VDD until the unit fails might show the fault.

I like to have several 100mfd caps around the board as well as .1 decouplers( habit from homebuilt UARTS with 7400 series chips). Also fat power traces and really good grounds.

Please keep up informed the more we know the more 'ideas' we can suggest.

Tom-H-PIC · Joined: 08 Sep 2003 Posts: 105 Location: New Castle, DE

I think that I have a good handle on the situation.
What I did is move all the 8 to 12 EEPROM address to new location.
Then I disabled all interrupts before writing to any EEPROM location.
I know the manual states that this is not required but can‘t hurt.
The original code was running about 95 to 98% full with the CCS CDC USB and all the features.
We remove two of the features that where never used.
This got the code down to ~83%.
The whole program is now more stable all the way around.
So we will see time will tell.
Anyways thanks everyone for all the help.
Tom

gpsmikey · Joined: 16 Nov 2010 Posts: 588 Location: Kirkland, WA

Another thought - perhaps we are looking at it wrong. Instead of assuming that locations are "not staying programmed", perhaps something in the code is writing to that location and trashing the data by writing something where it shouldn't. It might be interesting to see if there is any pattern in the data that is showing up in the changed locations.

mikey
_________________
mikey
-- you can't have too many gadgets or too much disk space !
old engineering saying: 1+1 = 3 for sufficiently large values of 1 or small values of 3