Code protection with MPLAB 7.60 and CCS 4.064

[Axel]

Hello,

I've been sitting all day trying to make MPLAB to enable code protection with little to no success. The CPU on the boards I'm programming are PIC18F65J10 and 67J10 and I've tried with #fuses PROTECT and setting it through the configuration bits window. Neither works as they should. Right now it looks like I'm going to have to manually patch the intel hex files at 0x7FF9 after compilation to clear the proper bit.

Am I missing something here? Has anyone else had this problem and if so, how did you resolve it?

Thanks in advance,
Axel Lindholm - Software engineer @ Martinsson Electronics

[ckielstra]

When you post a small example program we can test your problem. Right now it is guessing:
- MPLAB 7.60 is quiet old, why don't you use the newer 8.30 version?
- Do you have ICD=TRUE in your code? This will affect several fuses settings. Remove this line.

- Is the problem in the hex file or when programming?
- Which programmer are you using?

[Axel]

Thanks for the quick reply!

The reason for not using 8.30 is simply that it's the version we run where I work. Company policy simply, stupid as it may sound.

Yes, I do have ICD=TRUE

The problem is that the generated hex file contains a CONFIG1H register with bit 2 set (code-protection disabled).

I'm using the MPLAB ICD2 programmer.

I just tried removing the ICD=TRUE line and it works! Thank you very much for this bit of info. I'm not sure I'm going to use this tho since I found that clearing the bit manually with read/write_program_memory() does the trick and we'll be able to retrofit boards which has already been delivered with a non-protective bootloader this way. However, I'd really like to know why ICD=TRUE screwed things up for me. I suspect it may have something to do with the flash verification when programming the chip, or am I way off?

[ckielstra]

I never fully understood the use of the ICD=TRUE function. Like I mentioned, it does modify several fuses and maybe more. For example some of the old PIC16 processors require a NOP instruction at address 0 for the ICD to work correctly.

I don't like the implicit and hidden functionality, all required changes can be made with other commands and than you can see what is happening. For this reason I don't use the ICD=TRUE command in my code.

[bsturm]

I just learned something about the #device ICD=TRUE statement. I did not include it and the compiler mapped one of my variables into a reserved area of memory for the debugger. My program was behaving erratically and the watch window showed reserved memory instead of a value.

I found an option in MPLAB to turn on this +ICD fuse and the variable was OK. I then found it easier to add the line #device ICD=TRUE and comment it so I could remember to remove it for production.

[picdigger]

It is quite useful to check the fuse settings made by MPLAB using Configure->Configuration bits. Sometimes it's "funny" what you find there. Its a good way to "play" with the fuses without to start a real debug session.

BTW, the NOP operation needed at the program start will be replaced by a jump to the "debug-session" if the debugger will used.

[libor]

[picdigger]

Sounds strange, especially the RESET issue.

- Is the physical interface right, cross check it with the several AppNotes available from Microchip
- Is the clock stable? Use an oscillator to check this.
- Have you ever checked the ICSP using an oscilloscope? May be there are issues like:
-- voltage levels, ripple
-- timing variances (setup-hold-times)
-- clock too high if lines are too long
- Check the generated code using the mixed view (C+ASM) if there is still debug code included

[Sergio]

Hi Libor:

I'm real curious what you are using the ENIAC clone for and why.
_________________
Sergio

[PCM programmer]

It was a joke. You guys are taking his sarcasm seriously.