Fresh MCUs refuses interrupts

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Fresh MCUs refuses interrupts

Jump to solution
1,800 Views
larsl
Contributor II

Hi everybody!

I'm making a couple of PCBs with MKL04Z32xxx4 MCUs. Every time I try to boot up a new board for the first time, the interrupts just refuse to work. It doesn't matter if it's pin interrupts, UART interrupts, or PIT interrupts, they just won't work.

I've managed to get all of my boards eventually working by just power cycling, flashing, running, debugging, not really changing any code, but just simply repeating this procedure has seemed to work in the past. Last board took me about two hours to get the interrupts running, with the same code that other boards are running successfully. Yesterday I got a new board, different PCB than the others, and I'm having the same trouble getting the interrupts up again. This time it just won't work, whatever I seem to do.

It seems that this problem is not really related to my code, but there seems to be some sort of magical step I'm missing here. Has anybody had similar troubles?

Just for reference, my interrupts functions are registered in the NVIC vector, they are present and correctly linked while debugging and looking at the addresses in the NVIC Memory. In the example of PIN interrupts, the signal on the PCB generates the interrupt flag in the PCR register of the pin, but no interrupt is triggered...

Gear:

ARM MCU MKL04Z32xxx4

J-Link Lite debugger (SEGGER)

Eclipse IDE (not CodeWarrior)

Kind regards

LarsL

Labels (1)
1 Solution
992 Views
Jorge_Gonzalez
NXP Employee
NXP Employee

Hello larsl:

The FOPT register is actually volatile and its value is loaded from the corresponding flash field after reset. If you want to program default values in flash, you could include in your code a complete array with your preferred values for all the registers up to FOPT (last two bytes are reserved), just like suggested in the next thread:

Re: How to enable security on a KL15

Please be careful specially with the FSEC non volatile value, as you might end securing your device and/or disabling mass erase. Also keep an eye in the RESET_PIN_CFG bit from FOPT, since the reset pin can get disabled.

There is an easier way to do this with Processor Expert like showed with the next image, but this alternative can be tricky if your project was not set to use PE:

FOPT.png

And last, I leave this option from other post by colleague Derek Snell, but using IAR:

Using IAR EWARM to program flash configuration field

Hope this is useful :smileyhappy:

Kind Regards!

/Jorge

View solution in original post

0 Kudos
7 Replies
992 Views
carlos_chavez
NXP Employee
NXP Employee

Hello LarsL,

Do you have an interrupt handler for the NMI interrupt?  Is the NMI pin left floating by chance?  Can you observe this same behavior on the Freedom Board with your same code?

Look forward to hearing from you.

BR,

Carlos

992 Views
larsl
Contributor II

Hello Carlos!

You definitely know what you are talking about! I just came around to the same conclusion, that NMI had something to do with it, when I was digging through the ARM registers.

Our previous prototypes all had the NMI pin (PB5) floating. The current version has that pin as a clock input pin from another MCU. It seems that even though the code on my KL04 sets up the PB5 as a GPIO with IRQ16 it somehow still responds as a NMI.

The strange thing here is that the NMI handler is set to the default handler, which is just an asm("BKPT"), and that handler never gets triggered. Hence, the MCU never stops there, it just keeps running main() as if nothing happened. Which of course has made debugging this a whole lot harder.

For some reason it won't release the NMI functionality, which prevents all other interrupts from occuring. This is confirmed by looking at ICSR, it registers the NMI exception, currently has it as the active exception, even though the pin is reconfigured as GPIO/IRQ16.

Preferably, I would like the KL04 to not be dependent on what the other MCU puts on the line during boot. Do you have any idea of how to do this in the best manner? I've seen that I can set disable NMI functionality, by writing a byte to the flash, but I don't know if thats the correct way to go here. Ideally, the NMI functionality would just run it's exception until the pin is properly set up, and then not run anymore, but that doesn't seem to be the case...

Thank you for your time!

Kind regards

LarsL

0 Kudos
992 Views
carlos_chavez
NXP Employee
NXP Employee

LarsL,

I'm glad it got figured out.  If you are going to use PB5 as a GPIO and not have it be dependent on the state of the pin during boot up, then you should disable the NMI with a write to the appropriate Flash Configuration Field: 0x040D, which corresponds to bit 2 in the FTFA_FOPT[NMI_DIS].  Just so that you are aware, if this is done the NMI cannot be used as a source of wakeup from a low power state.

I hope that this helps.

Have a great weekend.

BR,
Carlos

992 Views
larsl
Contributor II

Thanks for the tip Carlos!

I know it is possible to write this flash field during booting, you wouldn't happen to know if there is an easy way to configure this register so that it is already done in the ELF file I flash to the MCU?

Have a great weekend you too!

/LarsL

0 Kudos
993 Views
Jorge_Gonzalez
NXP Employee
NXP Employee

Hello larsl:

The FOPT register is actually volatile and its value is loaded from the corresponding flash field after reset. If you want to program default values in flash, you could include in your code a complete array with your preferred values for all the registers up to FOPT (last two bytes are reserved), just like suggested in the next thread:

Re: How to enable security on a KL15

Please be careful specially with the FSEC non volatile value, as you might end securing your device and/or disabling mass erase. Also keep an eye in the RESET_PIN_CFG bit from FOPT, since the reset pin can get disabled.

There is an easier way to do this with Processor Expert like showed with the next image, but this alternative can be tricky if your project was not set to use PE:

FOPT.png

And last, I leave this option from other post by colleague Derek Snell, but using IAR:

Using IAR EWARM to program flash configuration field

Hope this is useful :smileyhappy:

Kind Regards!

/Jorge

0 Kudos
992 Views
larsl
Contributor II

Thank you for that thorough answer Jorge! I'll give it a shot first thing monday morning, but I'm quite sure it's gonna do the trick :smileyhappy:

Thanks for all the help, both Jorge and Carlos!

Kind regards

LarsL

992 Views
larsl
Contributor II

In case anybody else would be interested in this issue in the future, setting up this flash configuration field did help disable the NMI interrupts :smileyhappy:

Thanks to all involved!

LarsL

0 Kudos