How do you properly debug _int_default_isr()?

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

How do you properly debug _int_default_isr()?

1,612 Views
dave408
Senior Contributor II

I've got a project that (seemingly) all of a sudden stopped working.  I'm down to the point where the main object of interest has now been stripped of everything.  No inheritance, no members to initialize, pretty much a blank class with some empty methods.

When I run, I try to step into the constructor for the class and KDS just hangs.  When I click the pause button to figure out what's running, this is what I see:

pastedImage_0.png

As luck would have it, as I was running my code again to get the above screenshot, I was able to get some task information as well, which I previously hadn't been able to get:

pastedImage_1.png

MQX_UNHANDLED_INTERRUPT (0x0041) is pretty specific.  I'll start looking for that code.  If anyone knows what it is, please post it!  :smileyhappy:

Back to my original question, is the right process to follow:

  1. install hardfault, memory, etc. interrupt handlers (I have the four main ones)
  2. pause anytime your code execution seems stalled
  3. install the MQX task-aware debugging tools
  4. single step through the "frozen" code until you get task info, like I was fortunately able to get this time around?
0 Kudos
6 Replies

785 Views
ironsean
Contributor V

I am running into something similar:

I'm using MQX 4.2 and CodeWarrior 10.6.4 and code that seemed fine before has started to not work. I get an MQX_UNHANDLED_INTERRUPT error in my main task. What I'm doing when it happens is attempting to use sscanf() to parse a string.

I'm having a lot of trouble determining where the unhandled interrupt is coming from.

An answer in this guide seems to touch on it (General Technical MQX FAQ))

The document:

Q: How are exceptions or unhandled interrupts handled by MQX?

A: Basically, there are three ways of handling unhandled interrupts. They are mutually exclusive - in other words, you can only have one active at a time. You'd pick the one that best suits you for an application and use it:

1) _int_default_isr()
This is the default mode of handling interrupts - it simply blocks the offending task and sets its state to "Unhandled Interrupt Blocked"
2) _int_unexpected_isr()
This mode can be activated by calling _int_install_unexpected_isr() from the application. This will also block the offending task and set its state, but also will print some info on the console about who and what caused the unexpected exception
3) _int_exception_isr()
This is the most functional (but also most complex) of all the modes. It can be activated by calling _int_install_exception_isr().
Once this is installed, any unhandled interrupts will call _int_exception_isr(). It might help you understand the behavior of this function by actually looking at the code. It's in source\psp\\int_xcpt.c.


Here are the comments that define the behavior:
If an exception happens while a task is running, then:
if a task exception handler exists, it is executed, otherwise the task is aborted.
If an exception happens while an isr is running, then:
if an isr exception handler exists, it is executed, and the isr aborted otherwise the isr is aborted.
This is why you have to provide exception handlers.
For tasks, you install these with _task_set_exception_handler(). You would need to install a handler for each task in your system that you want handled (conceivably, this could be the same handler for all of them)
For ISRs, you install these with _int_set_exception_handler(). The parameter is the vector number of the interrupt your installing a handler for, not the exception vector itself (in other words, you'd install handlers for the vectors of ethernet, UARTs, timers, etc, not the divide by zero vector)
So, if you want to have full "handling" of all unhandled interrupts, you'll have to install handlers for all the tasks and ISRs that exist in your system. The handler itself could simply flag the error and allow the task to continue running. Other comments:
-Note that you shouldn't have to rebuild MQX libraries to change the modes - its simply done with a function call
-If one of the above three methods of handling unhandled interrupts does not suit you, you can also create your own handler to take whichever action you want and install it by calling _int_install_default_isr() with your own ISR as a parameter. This might be a simpler approach than using the exception handlers.

However, I'm running into an issue where _int_install_unexpected_isr() is installing the unexpected isr, but I'm not getting any output either on the console in Codewarrior, or over the virtual COM port where my printf calls print to.

This post (Unhandled Interrupt ) seems to include an example of using the exception isr, but it's also for MQX 3.5 but I don't know if it's still the proper implementation in MQX 4.2.

Sean

785 Views
danielchen
NXP TechSupport
NXP TechSupport

Hi

I think the post Unhandled Interrupt  can work on Cortex-M4 platform, you can have a try.

Regards

Daniel

785 Views
dave408
Senior Contributor II

Thank you both!  I will certainly give that a try the next time it comes up.

0 Kudos

785 Views
danielchen
NXP TechSupport
NXP TechSupport

Hi Dave:

Maybe you are getting out of memory, Have you checked the TAD and the memory pools?

Regards

Daniel

0 Kudos

785 Views
dave408
Senior Contributor II

I have not, but will try the next time around.  Can you point me to a document that explains everything that's available in the MQX menu?

pastedImage_1.png

0 Kudos

785 Views
danielchen
NXP TechSupport
NXP TechSupport

Hi Dave:

There are several documents about MQX with CW, please check the following folder.

C:\Freescale\Freescale_MQX_4_2\doc\tools\cw\

Regards

Daniel

0 Kudos