Kboot Disable NMI_b

[alex323qp]

Hi guys, I'm working in a custom board with the KL25Z64. PTA4 (NMI_b) is configured in my application as output with a pulldown resistor. When I run the app without the bootloader everything works fine, but when used in combination with the bootloader, nothing happens.

I reckon Kboot leaves the NMI_DIS (FOPT register) bit enabled by default, thus triggering the interrupt constantly and never running the main application.

I tried changing the flash configuration in my startup_MKL25Z4.s file from:

  .section .FlashConfig, "a"
    .long 0xFFFFFFFF
    .long 0xFFFFFFFF
    .long 0xFFFFFFFF
    .long 0xFFFFFFFE

to:

  .section .FlashConfig, "a"
    .long 0xFFFFFFFF
    .long 0xFFFFFFFF
    .long 0xFFFFFFFF
    .long 0xFFFFF7FE   /* Change here */

But it doesn't seem to work.

I also tried adding the NMI handler to my system_MKL25Z4.c and change the pin mode to ALT1 from there. But I'm not even sure if my interrupt handler is being triggered at all!!

void NMI_Handler(void)
{
  PORT_BWR_PCR_MUX(PORTA, 4, 1);     // Select ALT1
  FGPIO_SET_PDDR(PTA, 1 << 4);             // Make pin an output
  FGPIO_WR_PCOR(PTA, 1 << 4);             // Output LOW
}

I'm probably doing something very silly. Any help will be much appreciated.

Regards,

Alex.

[alex323qp]

Hi again,

After a few cups of coffee and reading this thread I managed to make everything work again by changing my flash config section from my illogical (it seems) ".long 0xFFFFF7FE" to ".long 0xFFFFFBFE". Now I can't help but wonder:

a) I was convinced that the right value was "... F7...". I arrived to this conclusion by analysing the FOPT register of the datasheet:

??=1, FAST_INIT=1, RESET_PIN_CFG=1, NMI_DIS=0, ??=1, LPBOOT=11

So, at the risk of asking something really dumb, can someone please point me out in the right direction (datasheet page # perhaps?) to understand the origins of 0xFFFFFBFE?.

b) Shouldn't my approach to change the pin mode in the NMI_Handler() have worked as well?

Thanks,

Alex.

[Hui_Ma · Accepted solution]

Hi

Please check blow abstraction from KL25 reference manual:

The NMI_DIS bit is located at FATA_FOPT bit2, that's why customer need to set 0b1011(0xB) to block NMI interrupt.

For the NMI_DIS bit is cleard, the NMI interrupt is blocked, customer does not need to change the pin function if this pin doesn't need be used for another function.

If this pin need be used as GPIO pin, customer need to call related code to set the pin muxing as GPIO function.

Wish it helps.

Have a great day,
Ma Hui
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[mjg8t]

Hi all,

I am having the same issue here and and have followed the instructions listed by Ma Hui, but the problem is not fixed (still getting non maskable interrupt).  

I have changed the flash byte values as below to disable the NMI_B bit in the startup_MK22F51212.S.  Using MK22FN512LH12.  Am I doing something wrong here - need to do something more?

/* Flash Configuration */
.section .FlashConfig, "a"
.long 0xFFFFFFFF
.long 0xFFFFFFFF
.long 0xFFFFFFFF
.long 0xFFFFFBFE
.text
.thumb

[mjbcswitzerland]

Hi

Don't forget that the same pin is used to enter the EzPort mode on the K22 - therefore 0xfffffbfe disables NMI but not EzPort. To disable both, 0xfffff9fe can be used.

Furthermore remember that only the boot loader can control this and not the application code, so the change needs to be in the boot loader.

Finally I would recommend NXP to remove the assembler code from the project and put it in C code using defines. It would make life easier, as well as making the code portable. There is no need to have assembler code and it only causes confusion and lack of portability.

To control the flash configuration in the uTasker project (also in its version of the KBOOT loader) it looks as below - much easier to understand, control and maintain (and no time lost by users trying to work out what the values mean).

Regards

Mark

// Flash configuration settings to be used
//
#define KINETIS_FLASH_CONFIGURATION_BACKDOOR_KEY      {BACKDOOR_KEY_0, BACKDOOR_KEY_1, BACKDOOR_KEY_2, BACKDOOR_KEY_3, BACKDOOR_KEY_4, BACKDOOR_KEY_5, BACKDOOR_KEY_6, BACKDOOR_KEY_7}
#define KINETIS_FLASH_CONFIGURATION_PROGRAM_PROTECTION (0xffffffff) // PROT[24:31]:PROT[23:16]:PROT[15:8]:PROT[7:0] – no protection when all are ‘1’
#define KINETIS_FLASH_CONFIGURATION_SECURITY          (FTFL_FSEC_SEC_UNSECURE | FTFL_FSEC_FSLACC_GRANTED | FTFL_FSEC_MEEN_ENABLED | FTFL_FSEC_KEYEN_ENABLED)
#define KINETIS_FLASH_CONFIGURATION_NONVOL_OPTION     (FTFL_FOPT_EZPORT_DISABLED | FTFL_FOPT_LPBOOT_NORMAL | FTFL_FOPT_NMI_DISABLED) // disable NMI and EzPort functions on NMI/EzP_CS input

// Fill out the flash configuration
//
const KINETIS_FLASH_CONFIGURATION __flash_config = { // set at 0x400 in linker script
    KINETIS_FLASH_CONFIGURATION_BACKDOOR_KEY,
    KINETIS_FLASH_CONFIGURATION_PROGRAM_PROTECTION,
    KINETIS_FLASH_CONFIGURATION_SECURITY,
    KINETIS_FLASH_CONFIGURATION_NONVOL_OPTION,
};‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

[mjg8t]

Thank you Mark.  I should have specified that I am not using Kboot, but just needed to solve the NMI_b and EZport conflict upon boot, which your 0xfffff9fe fixes.  It seems it would simply life for many to have these disabled by default, or like you mention a simple define to switch between modes during compile time.  How I wished you worked for NXP.