Note: KL26 is close enough to KL25 FREESCALE_FREEDOM_KL25Z" with minor differences in peripherals.
The security block inside hal_lld.c
Code: Select all
/*===========================================================================*/
/* Driver local variables and types. */
/*===========================================================================*/
__attribute__ ((section(".cfmconfig")))
const uint8_t _cfm[0x10] = {
0xFF, /* NV_BACKKEY3: KEY=0xFF */
0xFF, /* NV_BACKKEY2: KEY=0xFF */
0xFF, /* NV_BACKKEY1: KEY=0xFF */
:
:
I will be using a modified version of the Freescale startup code which has the block inside their assembly code, their security block is at the correct location.
Code: Select all
IF :LNOT::DEF:RAM_TARGET
AREA |.ARM.__at_0x400|, CODE, READONLY
DCB BackDoorK0, BackDoorK1, BackDoorK2, BackDoorK3
DCB BackDoorK4, BackDoorK5, BackDoorK6, BackDoorK7
DCB FPROT0, FPROT1, FPROT2, FPROT3
DCB FSEC, FOPT, 0xFF, 0xFF
ENDIF
Code: Select all
.ARM.__at_0x400 0x00000400 Section 16 startup_mkl16.o(.ARM.__at_0x400)
So please double check the map file to make sure that the security block is indeed when you think it is!
Might want to rethink that security block strategy to make sure that the compile cannot optimize it away. Don't make the assumption that if it is in the C code, then it will be in the image. What is the behavior of one compiler might not be the same on a different version or a different one.