Anyway to change the asm(HALT) statement in CPU_Interrupt?

[mhahn12419]

Using Processor Expert under latest CW version. Processor is MCF52110.

I wind up with a generic interrupt that handles all undefined interrupts:

__declspec(interrupt) void Cpu_Interrupt(void)
{
  asm(HALT);
}

I can change the function, but everytime I "Bring Up To Date" the interrupt gets changed back to the above code.

The above code is helpful during debug, but not optimal for a device installed in the field, since the device just hangs up (even the watchdog seems to be unable to restart it).

And yes I know I can use an interrupt bean, point all unused interrupts to a single ISR, and write my own ISR function. But adding 100 some beans seems needlessly painful.

Am I missing a radio-button or checkbox somewhere in CW?

Help!

Mark

[ProcessorExpert]

We are sorry but currently there is no such option in Processor Expert. We are planning to improve settings of unhandled interrupts on MCF in the next release of Processor Expert.

In the next release there will be an option to control the user code inside ISR routine and property to select one handler for all unused interrupts or own handler for each unsused interrupt.

For now as workaround you can disable code generation using menu commad "Freeze Generated Code" from menu bar "Processor Expert" and to edit the "CPU.c" file manually or to use "InterruptVector" bean.

best regards
Vojtech Filip
Processor Expert Support Team

[DRuffer]

Further on this, when can we expect an update to allow custom code in the unhandled interrupt routine?  Specifically, I want to know which interrupt caused this to happen, so I can track down a problem that I am seeing.  More specifically, on what should be a very simple MCF5213 project, using the Processor Expert, I am being constantly plagued by unhandled interrupts.  I have had to make it a habit to check almost every change I make to see if it has now created one.  So far, I have been able to come up with some alternative settings that allow me to keep going, but now I have one that happens every once in a while.  If I can't get some help on this quickly, I will probably have to resort to coding something myself, that probably pulls the information from the supervisor stack frame.

Any other suggestions would be appreciated.

DaR

[DRuffer]

Further on the unhandled interrupt I asked about last week.  After the HALT in CPU_Interrupt, SR= 0x2700 so we are in supervisor mode, A7=0x200061BC and at that memory address is:

20005DEC 200061E0 00002400 41B42000

This doesn't seem to make any sense that the vector would be 0 and FS would be 0.

What am I looking at, and why would it always be the same?

DaR

[ProcessorExpert]

Hello,

New version of Processor Expert for Coldfire V2-V4 including requested functionality is planned for the Q1 2010. Unfortunatelly I cannot provide more detailed infromation now. Workaround of this problem is mentioned in my response above.

In generall unhandled interrupt could by caused by incorrectly written code in user appliacation or for example by incorrectly set priorities in PE beans. Please note that each interrupt must be set to unique interrupt priority (for more detailes please follow this link).

In case the problem will persist we would need more detailed information including a simple project to reproduce the problem.

best regards
Vojtech Filip
Processor Expert Support Team

[DRuffer]

Thanks for the insight into the next version timing.  Unfortunately, I will be done with this project before you deliver.

It's looking like your advice about the interrupt priorities being unique is the solution I needed.  I was getting close to that same conclusion yesterday.  I just made them all unique and it seems to be running fine.  It's hard to prove the absence of a problem, but it sound like this is yet another thing that the PE needs to warn the user about.

Thanks!

DaR