PIC24EP problems protecting bootloader on aux flash memory

[SergioMForster]

I have developed a CAN bootloader that works very well, loading the user application that also works well.

The bootloader is in the auxiliary flash memory, while the user program is in the general flash memory.

I want to protect my code so that it cannot be read with external tools.

First I tried to read protect the bootloader.

These are the configuration fuses that works well:

[Ttelmah]

All PIC code, has to be able to read itself. If you disable code from
reading the actual code memory, this stops things like the loads done
at boot, which loads variables, from working. So just enable code
protection. This prevents external reads, but leaves the code able to read
itself.
Code protection can be left 'on'. You don't need to change things. Howver
your bootloader will need itself to have protection (encryption and a key)
otherwise this can be used to write a code block that then allows reading
of the memory.
Key to understand is that fuses that protect, generally cannot ever be
turned 'off' in a PIC without bulk erasing. This is done since otherwise
people could turn these off to access the chip. On chips with flexible
configuration, fuses like clock settings and ones affecting general
operation can be changed, but protection ones cannot.

[SergioMForster]

Ttelmah, Thank you very much for your help and your prompt response.

I understand what you are telling me, but I do not understand how I should do this code protection.

The only way I found in the documentation to protect the code, is using the PROTECT / GSSK fuses, for the general segment (the problem is that, with these fuses the bootloader resident in the aux memory cannot read the flash in the general segment, )
and APP / APK fuses for code protect the bootloader (with these fuses the bootloader does not start).

I am using the RESET_AUX fuse so that after the reset, the first thing to boot is the bootloader. At the beginning, the bootloader reads some flags in an external eeprom and a few bytes in the General segment flash to decide if it stays in bootloader mode or passes the control to the user program.

I have read in section 23.7.1 of Section 23. CodeGuard ™ Security document that it is necessary to disable the code protection in runtime to write/read the general segment and then in runtime to re-enable protection.


Once the boot loader verifies valid communication with the external programming tool, it can then
erase the code within the General Segment and clear the General Segment code protection.


As the boot loader finishes, it can program the Configuration bits to re-protect the general space,
make any necessary updates to the vectors and then return to the general application.



In summary

What I need is that the bootloader resident in aux memory can read and write without restrictions in the general segment flash.

And then from inside the chip the user program can read without restrictions within its own segment to read tables with read_rom_memory().

All I need is that neither the aux flash nor the general segment flash can be read from the outside using external tools.

Could you help me with some example of how to achieve it?

Thank you in advance.

[Ttelmah]

Now I'm working on a different chip, so setting names may differ.
However what I had to do was set GSS, and APL. Then ensure GSSK and
APLK bits _matched_ these settings. This left the chio unreadable
by an external programmer, but still programmable and readable by
the bootloader. It was vital that the key bits had the same settiings.
Otherwise full protection turns on.

[SergioMForster]

CCS support gave me a clue why the bootloader does not start when the auxiliary memory is protected, telling me that this problem is mentioned in the chip's errata sheet.


31. Module: Auxiliary Flash
When a device is set to obtain the RESET
instruction from Auxiliary Flash location,
0x7FFFFC (RSTPRI = 0), and Auxiliary Flash
code protection is enabled using the FAS register,
the device does not execute the application code
after a Reset. This configuration causes a security
trap resulting in a Reset.


This clears up one of the problems.

However, I cannot get the bootloader to update the general segment with the user's program with the protection of the FGS register (GSSK and GSS).

I can confirm that with the PROTECT and GSSK (0x31 on the FGS register) fuses the bootloader running from the Aux memory cannot read in the general segment flash (everything returns FF FF FF FF).

To write in the general segment flash, I am using the CCS library ><rom_write.c> that comes with the bootloader examples whose rom_modify (address, pointer, num) function needs to read from the flash with read_program_memory().

[temtronic]

OK, I have to ask 'why' do you need to 'protect your code' ? There are several 'low level' ways to deter 'reverse engineers', one of the simplest is to file/sand off the chips identity. One blob of epoxy looks the same as all the others ! This worked 4 decades ago...
Just curious..

Jay

[SergioMForster]

Finally I came to the conclusion that it is not possible, due to errata on the chip, to protect the code using bootloader in the aux flash memory

This was a comment from CCS Support with the same opinion

Unfortunately I don't see a way to use the Auxiliary Memory as the bootloader and protecting it or the General Segment from reads. Because of the errata when APROTECT is used it won't execute code from the Auxiliary memory. If you use Microchip's work around taking advantage of the other errata chip has by enabling read protection on the General Memory it also protects the General Memory from reads and writes from the Auxiliary Memory. As you found out once read protection is enabled in can't be disabled except for a bulk erase done with and programmer.

The only solutions I see is to not use the auxiliary memory as the bootloader and instead use a bootloader that is also located in the General Segment, see ex_pcd_bootloader.c for an example of this.