View previous topic :: View next topic |
Author |
Message |
E_Blue
Joined: 13 Apr 2011 Posts: 417
|
I neep help with Flash protection fuses on a PIC24FJ |
Posted: Tue May 17, 2022 12:11 pm |
|
|
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: 19504
|
|
Posted: Wed May 18, 2022 6:11 am |
|
|
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: 417
|
|
Posted: Wed May 18, 2022 2:14 pm |
|
|
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: 19504
|
|
Posted: Thu May 19, 2022 3:14 am |
|
|
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: 417
|
|
Posted: Thu May 19, 2022 6:58 pm |
|
|
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
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 |
|
|
|