Issue: PIC18F2550, PIC18F4550 Code Memory corruption.
Date codes tested 05044D9, 05062?B

Note. The information provided here is not meant to be
conclusive and is provided in good faith. It may well turn out
to be a false alarm though I do not expect that to be the case.

My tests show that certain, usually predictable, addresses in the
program memory are being corrupted during the programming
(writing to '0') of the TABLE READ PROTECT config bits.
When they are written down to a logic '0'  usually, the first byte
address location of the associated TABLE READ PROTECT block
will also be written  down to  '00'

Example;

Dummy program with 0xFFFF in all locations with TABLE READ
PROTECTION "ON" (It doesn't matter what you program, the result is
the same.

Results of a second verify done AFTER config word was programmed.

0000:   FFFF   FF00
0800:   FFFF   FF00
2000:   FFFF   FF00
4000:   FFFF   FF00
6000:   FFFF   FF00

This is typical of the fault I am describing. All other addresses are
as they should be. If I disable TABLE READ PROTECTION for
any of the blocks, then the write '00' problem does not occur for
that block.

I investigated the possibility that the problem was actually a false
reading and that the code space may still have the correct contents.
After all, this possibility does make sense. We are enabling a
READ protection.

My test for this was somewhat antidotal.  My own code would run
correctly when TABLE READ PROTECTION was off and the code
space read as expected. My code would NOT work when TABLE
READ PROTECTION was enabled and corrupt memory readings
occurred. (Not strictly conclusive but good enough for most of us
I'm sure.)

I have been able to show this problem occurs with the WARP-13
programmer and the Melabs serial programmer so it is does appear
to be not a programmer specific issue.

What is really of concern with this problem is that the corruption
occurs AFTER the program memory contents have been verified
and, expectedly, verified as being correct. This is standard MO
with all programmers. Verify before writing the config bits.

I am really wondering why I have not heard about this problem
previous to this. There is nothing in the errata sheets and nothing
about it in any of the forum boards I frequent.

I wonder if anyone is being affected by this problem without knowing
about it.

Can someone verify the presence or absence of this problem with
different programmers? Any further info from anyone on this?

Regards,

Jim Robertson
NEWFOUND ELECTRONICS












-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist