Why are interrupts not working in debug?

[malcolmmacdonald]

MCUXpresso 11.1.1, MKV42F64, barebone, PE Micro Multilink. I have interrupts set up on PIT and PORT. When I run the application without the debug interface, the program runs correctly, detecting external interrupts and providing the correct ticks. However, when in debug, the interrupts do not occur. I can see that the interrupt flags have been set in both the PIT and PORT registers, and there are NVIC entries for the appropriate vectors. But...no interrupts. Any explanations?

[malcolmmacdonald]

It appears that this NMI issue is far from rare ref. Interrupts appear to be disabled when debugging.pdf dates from 5 years ago! I wanted to fix this by updating the FOPT register, but trying to find where and how this is done in the code was proving difficult. I finally found the clue I needed at Getting Started: ROM Bootloader on the NXP FRDM-KL03Z Board | MCU on Eclipse (thanks, ErichS, you helped solve my problem almost three years ago!)

In startup/startup_mkv42f16.c (in my case), there is a section called Flash Configuration block with the following code:

__attribute__ ((used,section(".FlashConfig"))) const struct {
    unsigned int word1;
    unsigned int word2;
    unsigned int word3;
    unsigned int word4;
} Flash_Config = {0xFFFFFFFF, 0xFFFFFFFF, 0xFFFFFFFF, 0xFFFFFBFE};

The FB in the last word are the 8 bits of the FOPT value (different for other processors?). I changed it from the default 0xFFFFFFFE value to block all NMI after release from reset.

Problem resolved!

[ErichStyger]

Hi Malcolm Macdonald,

glad to hear that this was helpful for you.

Erich

[malcolmmacdonald]

Aha! Found it. It's the NMI. I'm using the pin as an input for something else. As long as it happens to be high during the start-up and initialization - there's a 50/50 chance this will be the case - the subsequent operation is correct, and that input will recognize Port interrupts with no problems (PIT interrupts also).

What still surprises me, however, is that, even with an uncleared NMI, other code is still executed. When I paused the processor, it was in a loop of my code waiting for the system tick which never came, and this is after all the initialization code. The pause also sometimes stopped in the file of weak interrupts, which is how I finally realized what was going on.

Also, the Reference Manual states that "The pin the NMI signal is multiplexed on, must be configured for the NMI function to generate the non-maskable interrupt request." and I am not sure how that configuration is being achieved (in order to stop it).

[ErichStyger]

What is the PRIMASK register saying in the 'Registers' view? Is it set to 0 (interrupts enabled) or 1 (interrutpts disabled)?

[malcolmmacdonald]

PRIMASK = 0, as is BASEPRI & FAULTMASK

[malcolmmacdonald]

More info. Finally, I changed to an identical, virgin board, flashed it with the same code, then ran it in debug. It worked! I added a line of code to enable another interrupt. Doesn't work. Back to original code - now not working. Grr! As the problem didn't seem to go away after leaving the device and PE probe un-powered for several hours, ruling out something in RAM, I wonder if I am somehow writing something unexpected to the device when I program it.

[Sabina_Bruce]

Hello Malcolm, 

Could you try separating your pit and port interrupts in two different examples. To see if it may be related to one or the other configuration.

Best Regards,

Sabina

[malcolmmacdonald]

I finally managed to get back to this - other priorities intervened.

My last entry was made with only the PIT running. Then I came back to it after a couple of days (powered off) and it worked. And then didn't again. My last recollection is that it seemed to be influenced by when the emulator is connected. However, coming back after almost a month, it is working just fine. Maybe because there is now no 'R' in the month?!