Hi All
There are often requirements to protect code programmed in embedded products and both the Kinetis and Coldfire MCU devices do thsi via their Flash Configuration.
The following is a short discussion of how this can be enabled in the uTasker project; details are specifically for the Kinetis (K64) but the Coldfires are very similar.
The device security is controlled by the standalone application or primary loader's Flash configuration stetting, which is defined in app_hw_kinetis.h
Eg:
KINETIS_FLASH_CONFIGURATION_SECURITY (FTFL_FSEC_SEC_UNSECURE | FTFL_FSEC_FSLACC_GRANTED | FTFL_FSEC_MEEN_ENABLED | FTFL_FSEC_KEYEN_ENABLED)
This is the case where no security is set.
The options are
#define FTFL_FSEC *(volatile unsigned char *)(FTFL_BLOCK + 0x02) // Flash Security Register (read-only)
#define FTFL_FSEC_SEC_SECURE 0x00 // MCU security status is secure
#define FTFL_FSEC_SEC_UNSECURE 0x02 // MCU security status is unsecure (standard shipping state of new devices)
#define FTFL_FSEC_FSLACC_DENIED 0x04 // freescale fatory access denied (only relevant in secure mode)
#define FTFL_FSEC_FSLACC_GRANTED 0x0c // freescale fatory access granted
#define FTFL_FSEC_MEEN_DISABLED 0x20 // mass erase is disabled (only relevant in secure mode)
#define FTFL_FSEC_MEEN_ENABLED 0x30 // mass erase is enabled
#define FTFL_FSEC_KEYEN_DISABLED 0x40 // backdoor key access disabled
#define FTFL_FSEC_KEYEN_ENABLED 0x80 // backdoor key access enabled
The values are described in the K64's user's manual in section 29.34.3 (FTFE_FSEC) {don't worry about FTFL and FTFE since these are two slightly different flash controller implementations, depending on part type. The uTasker project defines use just the FTFL names since the registers are in fact compatible}.
One just needs to set FTFL_FSEC_SEC_SECURE rather than FTFL_FSEC_SEC_UNSECURE. Generally don't disable mass erase (FTFL_FSEC_MEEN_ENABLED) since then it would not be possible to un-secure over debug or EzPort based on the mass erase command in case ever needed!!!
Once the secure mode has been configured neither the debugger interface nor EzPort will be able to debug/read memory. They will however still be able to command a mass erase and unsecure the device as a part of the process. It is recommended to check that the available tools correctly support unsecuring before use. Some debuggers don't let you set this mode (they protect to avoid risk of 'bricking' development boards) but EzPort programmers should do. In case of difficulties, contact the specific debugger manufacturer to find out how to allow the mode to be programmed.
For emergencies there is a define in debug.c (EZPORT_CLONER) in both Kinetis and Coldfire projects which adds an EzPort menu so that one board can be used to command a few things via EzPort to another board (when the wires have been connected), including erasing and un-securing. The idea was to include an EzPort cloning function (hence the define name) but presently only the commands have been used.
Regards
Mark
