Problem Securing Kinetis with MSD Bootloader

cancel
Showing results for 
Search instead for 
Did you mean: 

Problem Securing Kinetis with MSD Bootloader

Jump to solution
604 Views
nicholasf
Contributor III

I have been using the Kinetis MSD bootloader successfully for some time, but after changing the FTFE->FSEC 'SEC' bits in the 'cfm' section definition, the program does not load successfully on to the device.  When the K60 is being programmed, Codewarrior puts up a pop-up that says "Device is secure.  Erase to unsecure?" (despite the device not being secure), and whether yes or no is selected, the Codewarrior always displays this message: "No source available for "0xFFFFFFFE (0xFFFFFFFE)()", and never gets to 'main()'.  Changing other bits in the cfm section does not cause the same problem.  There are some threads on this forum which describe very similar problems, but none seem to solve the problem (in this case).  I have tried using Codewarrior with a PE Micro JTAG debugger, and using a Segger production JTAG programmer, with exactly the same result. 

Here are some of the resources I have found most relevant to the issue:

Setting Kinetis L Security with Codewarrior

Preventing Reverse Engineering: Enabling Flash Security | MCU on Eclipse

K60F120 No source available for "0xFFFFFFFE (0xFFFFFFFE)() "

http://cache.freescale.com/files/microcontrollers/doc/app_note/AN4379.pdf

http://cache.freescale.com/files/microcontrollers/doc/app_note/AN4507.pdf

Thanks for your time and attention.

edit:  I have been doing further testing, and Codewarrior is no longer giving the "secure" message, but the device is still crashing before getting to main.

Labels (2)
1 Solution
147 Views
nicholasf
Contributor III

We solved the problem, and the solution turned out to be quite simple, but there were some oddities which obscured the main issues:

1) Codewarrior will report that a uC is secured when it is actually unsecured if the active project is configured to secure the uC.

2) Setting the FTFE->FSEC[SEC] bits as 0b10 leaves the device unsecured, and 0b00 secures the device, but it is not possible for the SEC bits to be set to 0b01 or 0b11; in either of the last two cases, the uC is left insecure, and the SEC bits in 'cfm' read back as 0b10.

3) #2 applies whether using Codewarrior + PE Micro Multilink Universal or the (production programmer) Segger J-Flasher ARM, no matter what the .S19 file says.  The Segger programmer also causes the KInetis to crash on startup for unknown reasons when the SEC in 'cfm' has certain values.

4) Codewarrior cannot debug a processor which has the cfm set to secure it.

After finding out about and/or resolving these issues, we found that our main application was also crashing because the SIM->SOPT2[FBSL] was set incorrectly.

Thanks to everyone who read this thread!

View solution in original post

4 Replies
147 Views
nicholasf
Contributor III

The problem appears to be caused by the security register setting, as I tried putting the CFM definition in another project, and got the same issue.  For reference, this is the definition of the cfm (located at 0x400, and 0x10 long):

#pragma define_section cfmconfig ".cfmconfig" ".cfmconfig" ".cfmconfig" far_abs R

static __declspec(cfmconfig) uint_8 _cfm[0x10] = {

  0xFFU, // NV_BACKKEY3: KEY=0xFF

  0xFFU, // NV_BACKKEY2: KEY=0xFF

  0xFFU, // NV_BACKKEY1: KEY=0xFF

  0xFFU, // NV_BACKKEY0: KEY=0xFF

  0xFFU, // NV_BACKKEY7: KEY=0xFF

  0xFFU, // NV_BACKKEY6: KEY=0xFF

  0xFFU, // NV_BACKKEY5: KEY=0xFF

  0xFFU, // NV_BACKKEY4: KEY=0xFF

  0xFFU, // NV_FPROT3: PROT=0xF8

  0xFFU, // NV_FPROT2: PROT=0xFF

  0xFFU, // NV_FPROT1: PROT=0xFF

  0xFFU, // NV_FPROT0: PROT=0xFF

  0x7FU, // NV_FSEC: KEYEN=1,MEEN=3,FSLACC=3,SEC=2

  0xFFU, // NV_FOPT: ??=1,??=1,??=1,??=1,??=1,??=1,EZPORT_DIS=1,LPBOOT=1

  0xFFU, // NV_FEPROT: EPROT=0xFF

  0xFFU // NV_FDPROT: DPROT=0xFF

};

0 Kudos
147 Views
Carlos_Mendoza
NXP Employee
NXP Employee

Hi Nicholasf,

By setting the 0x7FU value on the Flash Security Register you are putting the MCU in a secure status:

0x7FU, // NV_FSEC: KEYEN=1,MEEN=3,FSLACC=3,SEC=3

pastedImage_0.png

If you don't want to secure the MCU you need to change the value to

/* NV_FSEC: KEYEN=1,MEEN=3,FSLACC=3,SEC=2 */ 0x7EU,

In case you you want to download a secured flash image to the MCU you need to use the “Flash Programmer” tool instead of launching a debug session, to do this you can follow these steps:

-       Click on the arrow next to the “Flash Programmer” icon.

-       Click on flash file to target.

-       Select the correct connection.

-       Make sure that the flash configuration file corresponds to the MCU being used.

-       Select the file to be flashed.

-       Uncheck the “Save as Target Task” option.

-       Click on Erase and Program.

Hope it helps!

Best Regards,

Carlos Mendoza

Technical Support Engineer

-----------------------------------------------------------------------------------------------------------------------

Note: If this post answers your question, please click the Correct Answer button. Thank you!

-----------------------------------------------------------------------------------------------------------------------

147 Views
nicholasf
Contributor III

Hi Carlos,

Yes, it is my intent to set the MCU to secure status, and I am only having issues when trying to secure the MCU. 

Directly flashing the bootloader to the target MCU does work, and the bootloader appears to operate correctly, but the main application (which ran fine with the unsecure bootloader) does not run when the MCU is secured.  I have also tried building the bootloader and including it in the main application project, with no success (not even the bootloader runs).  In addition, when we try to load the secure version of the bootloader with our production programmer, the bootloader does not work properly.

Thanks for your time and attention.

-Nicholas F

0 Kudos
148 Views
nicholasf
Contributor III

We solved the problem, and the solution turned out to be quite simple, but there were some oddities which obscured the main issues:

1) Codewarrior will report that a uC is secured when it is actually unsecured if the active project is configured to secure the uC.

2) Setting the FTFE->FSEC[SEC] bits as 0b10 leaves the device unsecured, and 0b00 secures the device, but it is not possible for the SEC bits to be set to 0b01 or 0b11; in either of the last two cases, the uC is left insecure, and the SEC bits in 'cfm' read back as 0b10.

3) #2 applies whether using Codewarrior + PE Micro Multilink Universal or the (production programmer) Segger J-Flasher ARM, no matter what the .S19 file says.  The Segger programmer also causes the KInetis to crash on startup for unknown reasons when the SEC in 'cfm' has certain values.

4) Codewarrior cannot debug a processor which has the cfm set to secure it.

After finding out about and/or resolving these issues, we found that our main application was also crashing because the SIM->SOPT2[FBSL] was set incorrectly.

Thanks to everyone who read this thread!

View solution in original post