Why ISR gets missed

[smita_joshi]

Hi

We have configured MK60FN1M0VLQ12 Pin 3(PTE 2) as an input pin for interrupt via SPI interface. We have configured interrupt on rising edge. We see that ISR gets called 4 -5 times and after that ISR gets missed. And in oscilloscope we see that interrupt pin is HIGH.

What could be the issue? Why ISR gets missed out?

How to increase interrupt priority of PTE2? We have tried disabling other interrupts but the issue persist.

Thanks

Smita

[mjbcswitzerland]

Smita

The priority of the port pin interrupt is set by the level that you define for the PTE source; Level 0 gives it highest priority.

If you have very fast changes it is possible to miss interrupts but it shouldn't be possible to lose a change to the '1' state.

Check your code carefully to ensure that you clear the original pending interrupt as early as possible in the interrupt handler so that a following change can become pending again, which will reduce the chance of missing edges - don't clear it after the interrupt handler has done its work or waiting for it to return to 0 since this may introduce a race state and risk clearing a pending interrupt that has not been handled..

I have attached the port interrupt code from the uTasker project (compatible with all Kinetis devices, including interrupts in KE/KEA parts) for comparison with an industrially proven solution.

Regards

Mark

Complete K60 solutions, training and support:http://www.utasker.com/kinetis.html
Kinetis K60:
- http://www.utasker.com/kinetis/TWR-K60N512.html
- http://www.utasker.com/kinetis/TWR-K60D100M.html
- http://www.utasker.com/kinetis/TWR-K60F120M.html
- http://www.utasker.com/kinetis/ELZET80_NET-KBED.html
- http://www.utasker.com/kinetis/ELZET80_NET-K60.html

[smita_joshi]

Hi Mark

Which Register do we need to configure to increase priority of Pin 3(PTE 2) of MK60FN1M0VLQ12?

We are loosing change to 1 state. This is because interrupt pin is HIGH, when we see ISR routine stop getting called. And ISR was called few times before that.

Below is our ISR.

PE_ISR(EInt1_Interrupt)

{

/* {Default RTOS Adapter} ISR parameter is passed through the global variable */

EInt1_TDeviceDataPtr DeviceDataPrv = INT_PORTE__DEFAULT_RTOS_ISRPARAM;

PORT_PDD_ClearPinInterruptFlag(PORTE_BASE_PTR, EInt1_PIN_INDEX);

EInt1_OnInterrupt(DeviceDataPrv->UserData);

//PORT_PDD_ClearPinInterruptFlag(PORTE_BASE_PTR, EInt1_PIN_INDEX);

}

void EInt1_OnInterrupt(LDD_TUserData *UserDataPtr)

{

if (int_cnt0 < 900)

{

adxl_xyz[int_cnt0] = adxl_read_XYZ_opt();

int_cnt0++;

}

else

int_cnt0 = 0;

// adxl_interrupt_enable();

}

Thanks

Smita

[mjbcswitzerland]

Hi Smita

You can set an interrupt priority for each port (not each pin). To set the priority on port E on the K60 you write the value to the corresponding NVIC register.

Eg. For level 6 the value is (6 << 4) is written to the IRQ91 PRIORITY REGISTER (which is in the IRQ88_91_PRIORITY_REGISTER in the NVIC).

From your description I am not yet convinced that you are losing interrupts and it could instead be a measurement problem: The fact that the input is '1' and you have had several interrupt doesn't report a problem in itself because there is no evidence as to whether the last change to '1' was counted or not.

How do you prove that the final rising edge was not handled?

Do you, for example, have a logic analyser recording of the input and an output being toggle on each handled interrupt, or set during the interrupt handling routine? Such a recording would be (fairly reliable) proof and may also show the reason for it at the same time.

Regards

Mark