Disabling NMI using the FOPT register (on KL17).

[rickstuart]

I am assuming what I need to do to fix my problem is to "Disabling NMI before execution".  But if in reading this you see my true problem, please do speak up!

I am using a KL17 in a situation where I need a GPIO pin more than the NMI.  So I reconfigure pin PTA4 for GPIO.  But when I enable all interrupts (and this only happens when I am debugging) my debugging session "goes south":

Wed Nov 04, 2015 11:18:57: The stack pointer for stack 'CSTACK' (currently 0x20000538) is outside the stack range (0x20002C00 to 0x20003000)

...why this (evidently) dose not happen when I am not debugging (the program sends messages to the UART port and communicates both ways over the SPI port) is a mystery to me.

So, I am assuming disabling NMI will fix this.  Even though I think there is another problem lurking in the wings.

I suspect changes can be made to the startup_MKL17Z644.s file to do this.  But after trying with no positive results (maybe a big endian problem?) we decided it a bit risky to continue with out understanding how this file is laid out.

Suggestions?

-thanks

[Hui_Ma]

Hi Rick,

About disable NMI function, please check below thread:

Re: Disable NMI_b pin/interrupt KL04Z?

Could you enlarge the stack memory size and check if the issue still there?

Have a great day,
Ma Hui

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

[rickstuart]

That other thread uses Processor Expert.  We didn't generate our code using Processor Expert.  So I would rather not start over.  Rather I would like to work with what I have so as to understand what needs to be done to fix this problem.

(I'm not sure if this is a problem with the stack memory size.  An IAR employee asked the same question (enlarge the stack memory size).  I believe this is something that is usually done from withing Workbench.  However, my copy of the project and my version of Workbench does not offer this "change stack memory size" option.  It is likely that the Workbench configuration file has been manually updated (maybe not even by me (i.e. I was given the configuration file this way)) and Workbench is now confused and refuses to make any further adjustments.  If you can describe a manual way to editing and change the file - that would be appreciated.  I assume this has to deal with *.icf files.)

However, I think the underlying problem here is not being able to get the Freescale NMI under control.  That is, not being able to turn it off from the get go!  I have tried over and over to change a section of code from a file called startup_MKL17Z644.s:

...

SECTION FlashConfig:CODE

__FlashConfig

		DCD    0xFFFFFFFF
		DCD    0xFFFFFFFF
		DCD    0xFFFFFFFF
		DCD    0xFFFF39DFE

__FlashConfig_End

...

If have tried changing "DCD 0xFFFF3DFE" to "DCD 0xFFFF39FE" to "DCD 0xFBFF3DFE" to "DCD 0xFFFB3DFE" to "DCD 0xFFFF3DFA" ... But nothing is making a difference.  I am still not able to run my code while the debugger is engaged and there is no 1K ohm pull up resistor on the NMI pin.  Again, the code runs fine with or with out the debugger engaged if there is a 1K ohm pull up resistor on the NMI pin.

-thanks for your help

[rickstuart]

I have been trying to disable the NMI by changing the FOPT byte for several days now.  The generated image must have the correct FOPT byte because it causes a warning every time I try to burn it into the processor using IAR Embedded Workbench IDE.  The warning says:

Tue Nov 10, 2015 17:45:42: Warning: Target inconsistency detected at Memory address 0x0000040D

So, since there are no responses here in a Freescale forum - could this possibly an IAR problem?  Maybe even an ARM problem?

-thanks

[dereksnell · Accepted solution]

Hi Rick,

When IAR warns you the location at 0x40D is inconsistent, it means the data at addess 0x40D read out of flash during the verification, does not match the data in your application image.  So you have not disabled the NMI in this case.  With IAR, this inconsistency is because by default, IAR writes safe values to FOPT and FSEC.  But you can force IAR to program those locations as you have in the image.  See Using IAR EWARM to program flash configuration field

When using the debugger, you can verify what's actually stored in FOPT using the debugger.  Using the Memory view to look at location 0x40D.  The data in location 0x40D is also copied to the FTFA_FOPT register.  So you can also use the debugger to look at the FTFA_FOPT register.  I suspect you will find those locations do not match what you have built in your application image.

Once you have the location 0x40D in flash matching what you have set in your application image, then you should see the NMI feature disabled.

Thanks

[rickstuart]

Thanks for you help Derek. The tricky bit now is to grab the right

IAR configuration files to place into our source code control. I

think they are the :

Derek Snell

replied to the discussion

"Disabling NMI using the FOPT register (on KL17)."

To view the discussion, visit:

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

>

[mjbcswitzerland]

Rick

This is IAR - there is a solution at Using IAR EWARM to program flash configuration field

The flash configuratin settings that I use for the KLx7 are

00 00 00 00 00 00 00 00 ff ff ff ff be 1b ff ff

and the NMI is disabled when loading with a tool that doesn't use its own value.

With IAR it programs 0xfe and 0x3d at the two fields of main interest by default.

For general development work you can just set the values that you want in its "board file".

Regards

Mark

Kinetis: http://www.utasker.com/kinetis.html

KL27: http://www.utasker.com/kinetis/FRDM-KL27Z.html / http://www.utasker.com/kinetis/Capuccino-KL27/Capuccino-KL27.html

For the complete "out-of-the-box" Kinetis experience and faster time to market

:smileyinfo: Out-of-the-box support for 46 Kinetis boards and 10 IDEs (460 combinations from a single code source with no porting required)