CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to support@ccsinfo.com

I neep help with Flash protection fuses on a PIC24FJ

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
E_Blue



Joined: 13 Apr 2011
Posts: 403

View user's profile Send private message

I neep help with Flash protection fuses on a PIC24FJ
PostPosted: Tue May 17, 2022 12:11 pm     Reply with quote

I have my firmware working ok, so now, I want to create a production HEX with the protection fuses on but, reading the PDF there's a lot of fuses to set because the PIC24FJ1024GB606 has a boot zone, and two partition zones.

I'm not currently using nothing of that, there's only one program with normal vectors, no boot zone, no partition zone, no 14 protection levels.
I just need something like the old CP fuse that protects all the Flash from readings, that's all.

So I currently using this line

Code:
#use delay(internal=32MHz,USB_FULL,ACT)
#fuses SOSC_LOW,SOSC_SEL,PROTECT_HIGH


But I get this fuses and seems like nothing is being protected.
What should I set to protect all the Flash?



https://ibb.co/whVnphn
_________________
Electric Blue
Ttelmah



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Wed May 18, 2022 6:11 am     Reply with quote

OK. You are running in single segment mode. So none of the alternative
boot and protection applies.
You need to look at the CSS, and GSS bits. These control the security
level applied to the configuration and general code respectively.
Now to be confusing CCS don't call the fuses CSS and GSS, but give
them 'friendly' names. These are:
PROTECT_CFG
PROTECT

The first sets the GSS fuse pattern to give standard protection for the
configuration data.
The second sets the CSS pattern to give standard protection to the code.

You can also select enhanced and high security modes for these, but you
then have to start getting involved with more complex rules (DS70005182).
I'd stick to standard protection.

Since you don't have a boot segment defined, the IVT (Vector segment),
automatically inherits the security from the code segment, so this
is protected as well.

Now this will prevent a bootloader from being used, If you want to use
one, then more complex settings become involved. It will also mean that
a full erase has to be performed whenever you want to program the chip.
E_Blue



Joined: 13 Apr 2011
Posts: 403

View user's profile Send private message

PostPosted: Wed May 18, 2022 2:14 pm     Reply with quote

So, if I want to protect configuration(Config word?) and program memory space I must to use both, PROTECT_CFG and PROTECT?

Is it worth it to protect configuration space?
I want to able to read if is protected or not.

I don't understand what's the difference between standard and high protection levels.

About the last paragraph, Are you saying that I must do it manually?
Because in the programmer setting I have "Erase all before program" option checked. Is not enough?

Thanks for your input.
_________________
Electric Blue
Ttelmah



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Thu May 19, 2022 3:14 am     Reply with quote

Depends on the programmer. CCSload will by default automatically erase
in this situation.
The protection fuses themselves cannot be cleared without a full erase,
but there are a couple of 'trick' ways round the protection if the config
bits are not protected.
The high protection level adds protecting when you jump/call between
segments. Should not make any difference in a single segment program,
but will if you start using multiple segments.
E_Blue



Joined: 13 Apr 2011
Posts: 403

View user's profile Send private message

PostPosted: Thu May 19, 2022 6:58 pm     Reply with quote

After many tries I remembered that there's a way to set the fuses manually, so I tried this

Code:
#fuses 1=0xFFFD9E//FSEC protection


Didn't work, the CSS bit refuses to set properly so I start to think that probably there's another line interfering with this bit for some reason.

It turned that a stupid

Code:
#device ICD=1


was the culprit.

I don't understand why but there's; it compiles a correct 0xFFFD9E to the FSEC fuse.

So many time wasted for this issue.
I'm happy and angry at same time.
_________________
Electric Blue
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
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