Hi,
we are using a K66FX1M0VMD18 processor with KDS 3.0, KSDK 1.2.0, ProcessorExpert and MQX.
From time to time, I observed that my software got stuck and the debugger stopped in dispatch.S at /* woohoo, idle task must be enabled, this point cannot be reachable, you have serious problem */. I found out that because of an an unhandled interrupt, the default ISR from MQX _int_default_isr() got called. The problem is, that this routine suspends the current task!! So if the current task coincidently is the idle task when the unhandled interrupt occurs, the idle task is blocked and there is no task left to run!
Is this a bug in MQX or how is _int_default_isr() meant to work? In my opinion, the idle task should never be blocked, even if unhandled interrupts or exceptions occur.
Best regards
Matthias
Hi Mathias,
could you share a simple project where we can reproduce this behavior?
Regards,
Carlos
Hi Matthias,
sorry for the delay. I am not getting why you dont want to install interrupts. This is the way interrupts should work in MQX. Please find attached a couple of examples.
In UART example I disabled MQX initialization to be able to control UART with the KSDK Driver.
Regards,
Carlos
Hello Carlos,
thanks for the reply. Sorry for the misunderstanding. Of course I want to install interrupts in a real project. I just did not install the interrupts in the example project to show what happens if an unhandled interupt occurs. In my opinion, the default interrupt handler _int_default_isr() should rescue my application if an unhandled interrupt occurs, but it seems that it does the opposite (blocks a random task so that the application can get stuck).
I know that there must be a bug in my original application so that the unhandled interrupt occurs. My question is how _int_default_isr() is meant to work. What is the reason for blocking the current task (e.g. idle task) if an unhandled interrupt occurs?
Regards
Matthias
Hi Matthias,
In embedded operating systems it is not usual to have a recovery routine as in general purpose systems. In this case it would be difficult to use default isr to recover from unhandled interrupt.
Regards,
Carlos
Hello Carlos,
I have attached a simple project for the FRDM-K64F board. The main task toggles the blue LED but is idle most of the time. When pressing the INT1 button an interrupt is generated. "Install interrupts" for PortC is disabled in the gpio1 component, so that the interrupt handler is not installed and _int_default_isr() in int.c is called instead. I had to add code to _int_default_isr() in order to clear the unhandled interrupt but now the project behaves in the same way as my application and if the button is pressed while the idle task is active (which is most of the time), the idle task gets blocked and we end up at ASM_LABEL(no_one_to_run) in dispatch.S.
Regards
Matthias