Losing programming

rwskinner · Joined: 08 Dec 2006 Posts: 125 Location: Texas

Hello to all. I have an odd problem that I need to try and find a solution to. I have a 18F4550 (bunches of them) that randomly lose their program after a power cycle.

The panel can be up and operating fine, a technician goes out, powers down the panel, performs maintenance, powers back up, and the board with the pic 18F4550 is a dead. Reprogramming the flash with the program fixes it but we rather not have to do this !

I have several thousand 16F chips, and 18F series chips out running and I only ran across this a couple of times after a severe lightening storm, but never after a normal power cycle.

I was able to copy the flash, programming bits, and eeprom off one before I reprogrammed it and I'm about to start comparing bits to see where it's getting corrupt at.

Any tips what I might look for?

PCM programmer · Joined: 06 Sep 2003 Posts: 21708

Microchip forum threads on power supply problems and lack of the
Brownout fuse causing Program Memory corruption:
http://www.microchip.com/forums/tm.aspx?m=509360
http://www.microchip.com/forums/tm.aspx?m=432788

asmallri · Joined: 12 Aug 2004 Posts: 1634 Location: Perth, Australia

rwskinner · Joined: 08 Dec 2006 Posts: 125 Location: Texas

I did have the CCS CDC Bootloader and just did away with it.
I also already had
NOLVP, BROWNOUT, and BORV20

I just set the following for Grins, Maybe it will help:
PROTECT
CPD
WRT
WRTD
WRTC
WRTB
EBTR
EBTRB
CPB

When I compared the hex I read from the device and the hex that I programmed the device with originally they were so different it wasn't even funny.

asmallri · Joined: 12 Aug 2004 Posts: 1634 Location: Perth, Australia

rwskinner · Joined: 08 Dec 2006 Posts: 125 Location: Texas

This is what I have. Previously, Brown out voltage was 2.0 volts and all memory was unprotected.

rwskinner · Joined: 08 Dec 2006 Posts: 125 Location: Texas

Ah, I overlooked the obvious, in the bootloader code, I did not have the fuses for Brownout and BOR set !!!

For Protection and Bootloader code, are these fuses ok?

PROTECT, NOCPD, NOWRT, NOWRTD, WRTB, WRTC, EBTR,EBTRB, CPB

This ought to protect everything but program memory and eeprom correct?

rwskinner · Joined: 08 Dec 2006 Posts: 125 Location: Texas

Since I have your ear, where are the CCS Fuses for Brownout and Powerup Timer for the 18F26J50? I see the Deep Sleep Brownout DSBOR.

CONFIG3L in the datasheet, describes the config bits but it's all for Deep Sleep.

Richard

Ttelmah · Joined: 11 Mar 2010 Posts: 19504

You do realise, that if you 'protect' the code, what you read back from a chip, will not resemble the hex file at all...
The 'verify' sequence with a chip with the protect fuse, is:
1) Write the chip without the protect fuse.
2) Verify against the hex file
3) Enable the protect fuse.
4) Read the data from the chip, and store it.
Then in future, program new chips, from the original hex file, but with the protect fuse set, and _verify_ against the file generated in step 4.

Best Wishes

obdave · Joined: 25 Sep 2010 Posts: 1

Howdy folks, I found this topic via Google because I just had one of my devices lose its mind. Here are particulars:

* processor is PIC18F25J11 (part of the PIC18F46J11 family)
* I have a bootloader
* processor went into a weird mode and stayed there
* rebooting umpteen times didn't resolve the issue
* code failed to verify using MPLAB ICD2
* flashing in new code via ICD2 fixed the problem

Sounds like program memory corruption to me.

Here's the thing - in studying the data sheet for this PIC, there is no fuse for Brown Out Reset. BOR is always enabled on this device, as is the internal voltage regulator. This PIC does have a Deep Sleep BOR fuse. I don't use Deep Sleep mode but I have the fuse enabled anyway. I'm not sure if I've overlooked anything or whether this is enough to eliminate BOR as a cause for my memory corruption.

Any suggestions would be gratefully accepted.

Regards,

Dave

PCM programmer · Joined: 06 Sep 2003 Posts: 21708

It could be any of the following, or several other things that are not listed:

Hardware:
1. A problem with your individual 18F25J11, or with the entire production
lot that your PIC is from.
2. A undiscovered errata with the silicon revision of your 18F25J11.
3. A problem with the design of your board, in the track layout,
component placement, and/or selection of component types or values.
Standard design practices may not have been followed.
4. A problem with a bad component on your individual board.
5. A misinterpretation of the PIC data sheet, so that the PIC on your
board is running outside of spec'ed design parameters. Or it could be
a misinterpretation of data sheets for other components on the board.
6. It could be a problem with the environment that the board operates
in, including electrical or temperature, etc.

Software:
7. It could be a problem with your version of the compiler. What is your
version ?
8. It could be a coding error done by you.
9. It could be the enabling of incorrect #fuses by you.

Here's a thread just on PCB track layout problems:
http://www.ccsinfo.com/forum/viewtopic.php?t=42775

The question is how to discover which of these things is causing the
problem. A lot of it can be done by swapping. Try using a similar PIC
from a "non-J" family. Try using a standard demo board from Microchip
as the platform, instead of your board. Try running the board in a
different environment. Try using a different CCS compiler version.
Try commenting out non-vital sections of your code. See if you still
get the problem.

Read my comments in this thread. See if you're doing any of those:
http://www.ccsinfo.com/forum/viewtopic.php?t=41964

assaad · Joined: 09 Dec 2009 Posts: 37