|
|
View previous topic :: View next topic |
Author |
Message |
jai
Joined: 12 Apr 2011 Posts: 11
|
ccsload: code not protected problem. |
Posted: Thu Jun 06, 2013 7:46 am |
|
|
Hi all,
I am programming the 16F887 with the fuses
Code: | #FUSES NOWDT
#FUSES HS
#FUSES NOBROWNOUT
#FUSES NOLVP
#FUSES MCLR
#FUSES PROTECT |
Also tried with this
#FUSES WRT_1000
same result.
Complete erase has also been tried.
But looks like the code is not protected. CCSLOAD 4.40 gives the message
CODE not protected after programming device.
please can somebody tell me what to do?
regards,
jaikumar.
Last edited by jai on Fri Jun 07, 2013 1:09 am; edited 1 time in total |
|
|
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Thu Jun 06, 2013 3:02 pm |
|
|
Are you compiling in Debug mode or Release mode ? If you compile in
debug mode, the compiler will change several of the fuses. That's
because the ICD debuggers will not work with, or do not support certain
fuses.
Here is an example program. Notice that I have Watchdog, code protect,
and brownout enabled:
Code: |
#include <16F887.H>
#fuses INTRC_IO, WDT, PROTECT, BROWNOUT, PUT, NOLVP
#use delay(clock=4M)
//==========================================
void main()
{
while(1);
} |
When I compile in Release mode, I get the fuses set the same way that
I specified in the program. This list is at the bottom of the .LST file:
Code: |
Configuration Fuses:
Word 1: 2FAC INTRC_IO WDT PUT MCLR PROTECT NOCPD BROWNOUT IESO FCMEN NOLVP NODEBUG
Word 2: 3FFF BORV40 NOWRT
|
But then I compile the program in Debug mode. Here is the fuse list
at the end of the .LST file:
Quote: | Configuration Fuses:
Word 1: 0CF4 INTRC_IO NOWDT NOPUT MCLR NOPROTECT NOCPD NOBROWNOUT IESO FCMEN NOLVP DEBUG
Word 2: 3FFF BORV40 NOWRT
Some fuses have been forced to be compatible with the ICD debugger. |
Notice that CCS has changed several of the fuses to "NO". So if you
want certain fuses to be enabled, make sure that compile in Release
mode. Do not try use the ICD for debugging (Breakpoints, etc) in Release
mode. "Release" mode means compile for production.
In MPLAB vs. 8.x, the selection of Debug/Release is done with a drop-
down box at the top of the MPLAB window. It's visible all the time.
I don't know how to select Debug/Release with the CCS IDE, because I
don't have it. I use the command line CCS compilers with MPLAB. |
|
|
jai
Joined: 12 Apr 2011 Posts: 11
|
|
Posted: Fri Jun 07, 2013 12:18 am |
|
|
Dear PCM programmer,
Thanks for the reply.
I am not on debug mode.
I also found that if i program without code protect and make a chip = file verify
there is a 100% match.
But when i set code protect with the fuses. When i do verification chip = file
I get a message
"
There are errors
Error patterns indicate code protection may be active.
"
The thing is the verification of code protection soon after programming always says "Code not protected" could this be a possible error in the programmer?
regards,
Jai. |
|
|
jai
Joined: 12 Apr 2011 Posts: 11
|
|
Posted: Fri Jun 07, 2013 12:42 am |
|
|
Hi all,
Yes i would like to confirm that there is a error in
CCSLOAD Programmer Control Software for Windows - 4.040 and 4.039
I tried v4.025 there is no error in that version.
It displays code protect verification message as it should.
I hope CCS will fix this.
Regards,
Jai. |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19568
|
|
Posted: Fri Jun 07, 2013 1:29 am |
|
|
You should never be able to 'verify' a code protected chip. Depending on the chip, older chips when read with code protection enabled, will return a 'scrambled' version of the code, while later chips just read as blank if code protection is enabled. Verify can't then work.
The 'standard' sequence to program a code protected chip, is to program and verify with code protection off, _then_ enable just the code protection fuse.
On older chips what you could do, was to program and verify a chip, then enable it's code protect fuse, and read the scrambled contents back. Save this. Then write new chips with the protection enabled, and verify them against the scrambled file. The same 'code' would always give the same 'scrambled' result.
It sounds as if 4.025, is not setting the code protect bits, hence the chip verifies...
I'd say that the later version is doing what it should. Refusing to verify if code protection is enabled.
However then have to point out that all these versions are at best 'beta'; compiler versions. It is generally held that first 'reasonably working' V4 compilers, were around 4.068 and later....
4.040, has to be perhaps three years old.
Realise you are talking about CCSLoad, not CCSC. So version numbering is different, but comment still applies. I'd say the newer version is doing what it should, and is not able to verify a code protected chip.
Best Wishes |
|
|
jai
Joined: 12 Apr 2011 Posts: 11
|
|
Posted: Fri Jun 07, 2013 6:44 am |
|
|
Dear Ttelmah,
Thank you for the info.
I think i should clarify the problem.
I understand that if not protected the verification must be chip = file.
and if protected chip not equal to file.
But the problem here is that in CCS programmer CCSLOAD V4.040 in the
settings tab there is a VERIFY ROM PROTECT AFTER WRITE.
Which when programmed with PROTECT should come after programming and display CODE PROTECTED.
This never happens - it always says NOT PROTECTED with fuse protect or not.
But it works on CCSLOAD V4.025.
regards,
jai. |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|