Code corruption

Marcs · Guest

I have have a code corruption problem with an PIC18LF4550

The problem was as identified as a block of 64 bytes in program memory being reprogrammed(erased?) to $ff.

Having read numerous posts I thought that blame could be attributed to the code's lack of fuse settings for:
Brown Out Protection
Write Protect
stack overflow reset
power up delay

From my understanding the main issue caused by these mechanisms is that the PC can go to any memory location randomly. For this to have caused the program memory erase problem it would need to have jumped to an erase program memory code segment.

However there is no such segment in the code. The nearest thing is a write to the EEPROM (generated by the CCS compiler being used):

Ttelmah · Guest

First thing, is this on more than one physical chip?. If not, it could simply be a chip fault. I have known chips that 'lose' a block without warning like this....

The first 'hardware' thing you don't mention, is is LVP enabled?. If so, then external hardware events on the LVP pins could cause this problem.

The second is the connection to the MCLR pin. Why 47K?. how long is the connection?. What else is near it?. The normal reason for using 47K, is if you are using ISP, since this is around the lowest resistor the programmers can drive high, without overloading their drives, and is large enough, so that the supply rail doesn't get pulled up significantly when they do. Unless you are using ISP, lower this value, and add a clamp diode, so the pin cannot go above the supply.

If you are not needing to write the memory from inside the code, why not try enabling the write protection fuses. If it still gives the problem, you have proved it is a chip hardware problem. WRTB,WRTC,WRT,CPB.

Best Wishes

marcs · Guest

Ttelmah

Thanks for the speedy reply

In answers to your points:

I have seen this on two separate occasions at random locations in memory.

The LVP is disabled in the fuse settings and I have confirmed this on the actual device using MPLAB

47k was used as it is a common value elsewhere on the board and a value i commonly use to pull up in applications where I am trying to save current wherever I can.
The 47k resistor is located adjacent adjacent to the pin on the pic and routed into a plane to get the power. The track is routed approx 20mm to a header for programming.
I can see no way that this can exceed the power rail, capacitive, emi, etc. As it is just a piece of 20mm track with a pull up at one end inside a metal enclosure.

I take your point about lowering the value and clamping. Belt and braces but it is not really viable at this stage as the products are out in the field.

Assuming some unknown event caused a spike on MClr is it likely that that could cause a block of program memory to be erased?

With regards to setting the protection fuses that will be my immediate action. I am hoping to duplicate the problem first to prove a fix but I am simply not seeing any other devices fail to test the fix against.

Marcs · Guest

Hi Ttelmah

You mention that you have seen devices which lose a block of memory.

In my case reprogramming the device was completely successful and despite power cycling the device I am not able replicate the problem.

Is this in common with your experience of lost memory blocks or was the device then rendered unusable?

cheers

Marc