Using IAR EWARM to program flash configuration field

[dereksnell]

There are non-volatile registers in the Kinetis family flash that store the default protection and security settings of the MCU.  These include the registers FSEC, FOPT, FEPROT, and FDPROT at addresses 0x40C - 0x40F.  IAR, like many toolchains, has added protection against programming these locations accidentally, mainly because some values for FSEC can permanently secure the flash, and prevent any future changes to the flash.  The default value IAR programs in these locations is 0xFEFFFFFF, which leaves the MCU unsecured and flash sectors unprotected.  If you desire your application to program these registers to a non-default value, it's not enough to have these values in the application.  By default, IAR will ignore these values in your application, and program the flash with the default setting.  Your project must specify you want to program these locations as well, and that is done using the parameter --enable_config_write in the .board file used by the flash programmer.  Here are the steps for enabling this parameter in IAR:

In the project options, go to the Download Tab in the Debugger category.  Check the box "Override default .board file"  Then click the Edit button

Select the memory range for the program flash, starting at address 0x0.  Click the Edit button

In the Extra Parameters field, add --enable_config_write.  Click OK.

The Flash Loader settings are updated with the extra parameter.  Click OK.

IAR will ask you to save these settings as a new .board file.  After saving the file, the .board file is updated with your modified file.  Click OK to save the project settings.   

Now you can program the flash and change the values in the flash configuration field at addresses 0x40C - 0x40F.

BE SURE your FSEC register at 0x40C is set to the proper value that you want.  A wrong value here can permanently secure the flash, and your board will become a nice paperweight!

As a reference, here is the modified FlashK60Fxxx128K_enable_config_write.board file from this example:

<?xml version="1.0" encoding="iso-8859-1"?>


<flash_board>
  <pass>
    <loader>$TOOLKIT_DIR$\config\flashloader\Freescale\FlashK60Fxxx128K.flash</loader>
    <range>CODE 0x0 0xfffffff</range>
    <args>--enable_config_write</args>
  </pass>
  <pass>
    <loader>$TOOLKIT_DIR$\config\flashloader\Freescale\DFlashK60Fxxx128K.flash</loader>
    <range>CODE 0x10000000 0x13ffffff</range>
    <abs_offset>0x800000</abs_offset>
  </pass>
</flash_board>

[hadarm]

hi derek,

i use at  STM32H743xI/G in IAR EWARM and now i moved 64 bytes using the USB to the application and i tried to extend the buffer to 2K and its not working

do you have any solution for me?

thanks,

hadar

[Kratz]

Dave, I found your post helpful after not understanding why the flash protect would not enable through programming. 

My program has been written and is ready for securing the flash.  My problem after putting in --enable_config_write is a message appears after programming the chip: Warning: Stack Pointer is setup to incorrect alignment. Stack addr = 0xFFFFFFFF.   The processor is an M0+, MKE02Z32.  Did my project completely ignore the configuration file.  What am I missing?   When removing --enable_config_write the problem goes away, and the program runs.

[narasimhaugra]

Hi Derek

is there any way to read these register what value is present there?

Am using MKM34z256vll7 family kinetics controller and not able to program it. I want to confirm that my device is not locked

I use IAR, ARM am getting the following error while downloading the firmware 

"The flash loader program reported an error"

"A fatal error has occurred, the debugger will terminate"

I use a PE-micro multi link universal debugger, and i checked the voltage of different pin, and the supply  voltage, and all is correct, and the device is identified correctly.

Please help me how to unlock the MCU.

Best,

Ugra##

[narasimhaugra]

Hi NXP team,

Please help on this....!

Best,

Ugra

[surrealist14]

Hi Derek,

I am working on a serial bootloader project using uTasker's Serial Loader (a really GREAT product with excellent support, by the way). 

I am using IAR 7.40.3, and a Segger J-Link JTAG pod.  I have the configuration protection bits programmed as:

    #define KINETIS_FLASH_CONFIGURATION_PROGRAM_PROTECTION (0xfffffffc)  // PROT[24:31]:PROT[23:16]:PROT[15:8]:PROT[7:0] - no protection when all are '1'

which should protect to two lowest blocks.  My application code is linked above these two blocks, and I download it via the serial loader.

I followed your instructions, and added --enable_config_write to a .board file.  Here is the content:

<?xml version="1.0" encoding="iso-8859-1"?>

<flash_board>

  <pass>

    <loader>$TOOLKIT_DIR$\config\flashloader\Freescale\FlashK60Dxxx128K.flash</loader>

    <range>CODE 0x0 0xfffffff</range>

    <args>--enable_config_write</args>

  </pass>

  <pass>

    <loader>$TOOLKIT_DIR$\config\flashloader\Freescale\DFlashK60Dxxx128K.flash</loader>

    <range>CODE 0x10000000 0x13ffffff</range>

    <rel_offset>0xf0800000</rel_offset>

  </pass>

</flash_board>

The first time, I am able to Download and Debug the application with no problem.  However, if I try to Download and Debug again, I get the following errors back via dialog boxes:

"The flash loader program reported an error."  I click OK, then get:

"A fatal error has occurred.  The debugger will terminate.".  I click OK, but am stuck not being able to program my project into Flash.

Using the same .board file, I tried using Project/Download/Erase Memory, and selected Erase All.

The Debug Log reports that Flash memory was erased:

Fri Nov 20, 2015 18:07:50: Loaded macro file: C:\Program Files (x86)\IAR Systems\Embedded Workbench 7.40\arm\config\debugger\Freescale\Kxx.dmac

Fri Nov 20, 2015 18:08:19: Loaded macro file: C:\Program Files (x86)\IAR Systems\Embedded Workbench 7.40\arm\config\flashloader\Freescale\FlashK60Xxxx128K.mac

Fri Nov 20, 2015 18:08:20: JLINK command: ProjectFile = C:\Natus-EACS\SignalController\uTasker\Kinetis_14-9-2015\Applications\uTaskerSerialBoot\IAR7_Kinetis\settings\uTaskerSerialBoot_FLASH.jlink, return = 0

Fri Nov 20, 2015 18:08:20: Device "MK60DN512XXX10" selected.

Fri Nov 20, 2015 18:08:20: DLL version: V4.98e, compiled May  5 2015 11:00:52

Fri Nov 20, 2015 18:08:20: Firmware: J-Link ARM V8 compiled Nov 28 2014 13:44:46

Fri Nov 20, 2015 18:08:20: JTAG speed is initially set to: 32 kHz

Fri Nov 20, 2015 18:08:20: TotalIRLen = 4, IRPrint = 0x01

Fri Nov 20, 2015 18:08:20: TotalIRLen = 4, IRPrint = 0x01

Fri Nov 20, 2015 18:08:20: Found Cortex-M4 r0p1, Little endian.

Fri Nov 20, 2015 18:08:20: FPUnit: 6 code (BP) slots and 2 literal slots

Fri Nov 20, 2015 18:08:20: CoreSight components:

Fri Nov 20, 2015 18:08:20: ROMTbl 0 @ E00FF000

Fri Nov 20, 2015 18:08:20: ROMTbl 0 [0]: FFF0F000, CID: B105E00D, PID: 000BB000 SCS

Fri Nov 20, 2015 18:08:20: ROMTbl 0 [1]: FFF02000, CID: B105E00D, PID: 003BB002 DWT

Fri Nov 20, 2015 18:08:20: ROMTbl 0 [2]: FFF03000, CID: B105E00D, PID: 002BB003 FPB

Fri Nov 20, 2015 18:08:20: ROMTbl 0 [3]: FFF01000, CID: B105E00D, PID: 003BB001 ITM

Fri Nov 20, 2015 18:08:20: ROMTbl 0 [4]: FFF41000, CID: B105900D, PID: 000BB9A1 TPIU

Fri Nov 20, 2015 18:08:20: ROMTbl 0 [5]: FFF42000, CID: B105900D, PID: 000BB925 ETM

Fri Nov 20, 2015 18:08:20: ROMTbl 0 [6]: FFF43000, CID: B105900D, PID: 003BB907 ETB

Fri Nov 20, 2015 18:08:20: ROMTbl 0 [7]: FFF44000, CID: B105900D, PID: 001BB908 CSTF

Fri Nov 20, 2015 18:08:22: Hardware reset with strategy 2 was performed

Fri Nov 20, 2015 18:08:22: Initial reset was performed

Fri Nov 20, 2015 18:08:22: Found 1 JTAG device, Total IRLen = 4:

Fri Nov 20, 2015 18:08:22:  #0 Id: 0x4BA00477, IRLen:  4, IRPrint: 0x1 CoreSight JTAG-DP

Fri Nov 20, 2015 18:08:22: ----- Prepare hardware for Flashloader -----

Fri Nov 20, 2015 18:08:22: 2560 bytes downloaded and verified (20.00 Kbytes/sec)

Fri Nov 20, 2015 18:08:22: Loaded debugee: C:\Program Files (x86)\IAR Systems\Embedded Workbench 7.40\arm\config\flashloader\Freescale\FlashK60Dxxx128K.out

Fri Nov 20, 2015 18:08:22: Target reset

Fri Nov 20, 2015 18:08:23: Unloaded macro file: C:\Program Files (x86)\IAR Systems\Embedded Workbench 7.40\arm\config\flashloader\Freescale\FlashK60Xxxx128K.mac

Fri Nov 20, 2015 18:08:23: Loaded macro file: C:\Program Files (x86)\IAR Systems\Embedded Workbench 7.40\arm\config\flashloader\Freescale\FlashK60Xxxx128K.mac

Fri Nov 20, 2015 18:08:23: ----- Prepare hardware for Flashloader -----

Fri Nov 20, 2015 18:08:23: 2560 bytes downloaded and verified (2.54 Kbytes/sec)

Fri Nov 20, 2015 18:08:23: Loaded debugee: C:\Program Files (x86)\IAR Systems\Embedded Workbench 7.40\arm\config\flashloader\Freescale\FlashK60Dxxx128K.out

Fri Nov 20, 2015 18:08:23: Target reset

Fri Nov 20, 2015 18:08:23: Unloaded macro file: C:\Program Files (x86)\IAR Systems\Embedded Workbench 7.40\arm\config\flashloader\Freescale\FlashK60Xxxx128K.mac

Fri Nov 20, 2015 18:08:23: Flash memory has been erased.

Note that it "claims" that Flash memory has been erased.  However, if I try to Download and Debug again, I get the same error "The flash loader program reported an error."

Partly out of desperation, I tried the J-Flash Lite utility provided by Segger.  Under Target device selection, I selected Freescale, then MK60DN512xxx10 (allow security) and clicked OK.  I selected JTAG as the interface, and left Speed at the default of 1000.  I then clicked OK.

At the next dialog box, I clicked "Erase Chip".  I received a dialog box that said "Active Kinetis write protection detected.  This could cause problems during flash download  Do you want to perform a mass erase of the device in order to remove flash write protection?  If "Do not show this message again" is selected, mass erase will be performed automatically in the future."  I clicked Yes to erase the chip, which appeared to work successfully, and then exited J-Flash Lite.

I was then able to go back into IAR and Download and Debug - again, only the first attempt was successful.  It appears that the --enable_config_write option is not working as expected.

Can you think of any reason why this would not work, or some setting that I might have missed?  Having to go to an external program to erase the chip is painful and seems unnecessary, since that apparently is the purpose of the --enable_config_write parameter.

Thanks for any help you can provide!

Scott

[dereksnell]

Hi Scott

It sounds lik your application is securing the device by programming the security bits in the FSEC location in flash at address 0x40C. The two least significant bits in that byte control the flash security, and if the are not 0b10, then the device will be secured after programming it. Then it requires a mass-erase to unsecure the device

So please check that location in your application, and you can update it to leave the device unsecured.

Thanks

[mjbcswitzerland]

Scott / Derek

I took a look into the IAR behavior. The fact is that IAR can't handle the case when the first block is protected by setting 0x408 to 0xfe (to set protection on the first 1/32 of the Flash). Because the start is protected from modification it can neither load code nor perform an erase.

This has nothing to do with flash security which is still Ok since the debugger can connect and one can see that the FPROT3 register setting is as expected (it looks like IAR may do something nasty too since the Flash line at 0x400 can no longer be read back - typicial for when a phrase in the line has been programmed more than once).

Note that this also has nothing to do with the --enable_config_write setting since it the same with or without it.

Although it should be possible to perform a mass erase (under debug control) to recover from this, IAR fails.

Other tools, such as KDS, don't have problems loading new code in this state.

Therefore this is probably something that IAR needs to solve.

In the meantime it is still possible to use Flash protection by loading the image using alternative tools and using IAR just for connecting and debugging.

A second workaround is to leave the Flash protection settings at 0xffffffff but write FTPROT3 to 0xfe immediately in code once the loader has started*. This also activates the equivalent protection (with a very small window between reset and the instruction which allows the IAR debugger to be able to work).

*Scott
You can add

FTFL_FPROT3 = 0xfe;

in kinetis.c just before

__iar_program_start();

to achieve this so that you can work normally with IAR and not need other tools to fall back on.

Regards

Mark

[surrealist14]

Thank you, Derek and Mark.  I appreciate your ideas, and have become convince that IAR must have a problem with their K60 flash loader.

Derek, leaving the write protection bits unprogrammed is not really a good solution, since we want to prevent accidental erasure of those two blocks, which will contain a serial loader that will be used to permit in-field updates of our application code.

I discussed our situation with a local representative of Segger, and on his recommendation, updated our J-Link software to V5.02k, allowing it to update the DLL that is used by 3rd-party tools such as IAR also.

Under project options, I then made sure that I had the Freescale MK60DN512xxx10 selected, and then, under Debugger/Download, I _unchecked_ the box that says "Use flash loader(s)".  This tells IAR EWARM to use the J-Link's flash loader instead.  Once I did this, I tried to Download and Debug again, and got a dialog box from J-Link V5.02k indicating:

"Active Kinetis write protection detected.  This could cause problems during flash download

Do you want to perform a mass erase of the device in order to remove flash write protection?

If "Don not show this message again" is selected, mass erase will be performed automatically in the future."

I clicked Yes, and the download completed successfully.  I then exited IAR EWARM and reloaded the same workspace to try it again, and got the same dialog.  It looks like using the J-Link downloader instead of the IAR downloade unlocks the secured memory correctly.

I have sent this information to IAR support, since it solves my problem, but it is not a general-purpose solution for others who might be using a different connection to a K60 target.  I believe that IAR has a problem with their flash loader software, so the only general-purpose "fix" to to fix the flash loader itself.

Hope this helps, and thank you both very much for your efforts and advice.

Scott

[dongyangli]

Also, when I download the program, download debugger returned:

Wed Oct 07, 2015 10:28:51: Skipping flash loading pass because there is no data in the designated range: 0x10000000-0x13FFFFFF.

I wonder what is the configuration for the PE programer in the IAR?

[dereksnell]

Hi Dongyang Li

The error messages shown below indicate the NAND flash is not formatted, and the application cannot find the file resources.pbr which needs to be programmed in the NAND flash.

NOT A DOS DISK! You must format to continue.

PEG Opening resources.pbr from NAND FFS...FAILED!

Please follow the steps to format and program the NAND flash in the user guide at

http://community.freescale.com/docs/DOC-100958

The message "Skipping flash loading..." is not an issue, because that range of memory is not the internal flash.

Also, if you have any further comments or issues specific to the Cloud-Connected ZigBee Thermostat, please post them at the demo page, at the same link above.

Thank you

[dongyangli]

I think I almost run the demo, LCD is work, two zigbees are paired

already. however the data received from zigbee can't display on the

LCD screen.

I wonder why is that

引用 dereksnell <admin@e11339.dscb.akamaiedge.net>：

Derek Snell

replied to the discussion

"Using IAR EWARM to program flash configuration field"

To view the discussion, visit:

https://community.freescale.com/message/575250?et=watches.email.thread#575250

>

[dongyangli]

I think I have fixed that problem, the demo works now. Thanks.

However the TWR-RGB-LCD doesn't work stable. After I program to flash

and powerup the system. The terminal also return correct. But most of

time, LCD just shows white screen. After I touch the screen, the image

may show up. Most of time it is just show nothing, but terminal return

resource.pbr is success.

I wonder why is that, BTW, I have use external power supply to tower system.

引用 dereksnell <admin@e11339.dscb.akamaiedge.net>：

Derek Snell

replied to the discussion

"Using IAR EWARM to program flash configuration field"

To view the discussion, visit:

https://community.freescale.com/message/575250?et=watches.email.thread#575250

>

[dongyangli]

Hi, I am running the demo:

Freescale Cloud-Connected ZigBee Thermostat Demo

which is you provide. I assembled all the boards and downloaded the program from IAR as you provide.

However the LCD doesnt work, and from the UART console, it returned:

Shell (build: Apr 16 2014)
Copyright (c) 2013 Freescale Semiconductor;
shell>
shell> driver assert at Hcd_Init:1055
NOT A DOS DISK! You must format to continue.

PEG Opening resources.pbr from NAND FFS...FAILED!

I wonder what I am doing wrong? I use PE programe driver in IAR to download program. Is that cause any problem. How do you download the program in IAR?

[Dealerz]

Has anybody figured out how to modify the icf file correctly to setup up the correct programming of the address space for the registers?

[weblar]

Hi Jason,

I'm presently trying to figure out how to modify the ICF file to include the relevant "section".

I've modified the .board file as per Derek's instructions above however I get the following error in IAR when trying to program my K60:

"Could not write CPU register R0: Written: 0x40052000, Read 0x05FA0004"

Whether this is because the ICF file is incomplete, I don't know. Reverting back to the default .board file gets rid of the error.

Regards,
Kevin

[Roguetroop]

Derek,

     Thank you for this write up. I followed your directions and the IAR dialog boxes and the generated board file looks exactly like the ones in your write up. I modified the "hello" example in the MQX examples directory and added the following:

#pragma location = 0x0400
	unsigned char backdoor[8] = {0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF};
#pragma location = 0x0408
	unsigned char FPROT[4] = {0xFF, 0xFF, 0xFF, 0xFF};
#pragma location = 0x040C
	unsigned char FSEC[1] = {0xF7};
#pragma location = 0x040D
	unsigned char FOPT[1] = {0xFF};
#pragma location = 0x040E
	unsigned char FEPROT[1] = {0xFF};
#pragma location = 0x040F
	unsigned char FDPROT[1] = {0xFF};

However, after building and running, I can see in the register view that FSEC is still 0xFE. Can you please let me know what I am doing wrong? Thank you.

[larryc]

@Derek -

I believe you have to add a section name to the pragma's to change the flash config locations, then mod the icf script to place that section in the correction location.

The method also seems to vary based on which version of EWARM you are using.

Larry

[manjitduhan]

Hi Derek

is there any way to read these register what value is present there?

Am using FRDM-KE02 board and not able to program it. I want to confirm that my device is not locked

Regards

Manjit Singh

[dereksnell]

Hi Manjit,

The debugger can always read the MDM-AP register, and if the flash security is enabled, then this register will show it. That register also shows whether mass-erase is still enabled, and if so, the flash can be unsecured. Since the debugger won’t be able to connect if the flash is secured, you typically need the debugger script to read the MDM-AP register. If you can’t find one for your debugger, you can modify the existing script to read and display that register.

This post has an example of a debugger script for the J-Link in IAR

https://community.freescale.com/message/305665#305665

Thanks