Coldfire Software Interrupt

[arlo]

I am trying to figure out how to cause a software interrupt on my MCF51QU128 processor but cannot figure how to do that .  I have looked through the documentation (I am sure I am reading right over it not really understanding what it is trying to tell me) .  I want to avoid using TRAP instructions because I think it is the wrong tool for the job. A simple example or detailed explanation would help loads at this point.

Thanks in advance!

[wernermotz]

Hello,

I could need some help implementing an ISR. I am using CW 2.10 for MPC55xx.

Although I did everything Stanislav told, my FLEXRAY_ISR Handler is never called.

Instead always the EXCEP_DefaultExceptionHandler() is called. What did I wrong?

INTC_InitINTCInterrupts();

INTC_InstallINTCInterruptHandler(FLEXRAY_ISR, 352,2);

INTC.CPR.R = 0;

asm("wrteei 1");   

Enable_interrupts();

void FLEXRAY_ISR(void)

{

...clear channel interrupt flag....

}

Please help me. I am looking forward to your answers.

[arlo]

Thanks for your explanations.  I am new to the industry and don't want to follow the "wing it 'till you get it" principle.  Your explanations were perfect.

[JimDon]

Not sure why you think traps are "wrong" and software interrupts are "right".

In any event, this is an example of using traps (which, are really software interrupts - see how you put a vector in the interrupt table?).

 Interrupt VectorNumber_Vtrap0  void TRAP_0(void) {  dword s,p0,p1,p2;  asm {   move.l D0,s   move.l D1,p0   move.l D2,p1   move.l D3,p2  }   }int SERVICE_0(dword s,dword param0,dword param1,dword param2){ asm {  move.l param0,D1  move.l param1,D2  move.l param2,D3  trap #0 } return 0;}

[TomE]

---

JimDon wrote:

Not sure why you think traps are "wrong" and software interrupts are "right".

A Trap happens NOW.

A Software Interrupt can be triggered, but can run LATER when the CPU's priority is low enough.

A common application is splitting a hardware driver into a high-priority and low-priority part without needing a polling loop or a dedicated thread to handle the low priority bit. You just run the "low priority" part as a software interrupt, triggered from the high priority one. The low priority part doesn't run until all higher priority interrupts have been services, and can be interrupted by other higher priority ones.

You can't do that with a Trap.

if you've never coded on a CPU with Software Interrupts before you may not think of the above architecture. If you have, you may not want to code any other way. The original poster might be porting code that relies on Software Interrupts and won't run (easily) without them.

Tom

[JimDon]

Upper and lower drivers might be a good application.

If you are using  the software interrupt as a method to dynamically link to services, a trap is the way to go, as you are really looking for a dynamic linkage, or  functionally a sub routine call.

Triggering a an interrupt to be processed on another "thread" would be of no use at all in this context, so we are not really comparing apples to apples here.

Which is why I said:

Not sure why you think traps are "wrong" and software interrupts are "right". 

In the coldfire, traps and swi interrupts are both considered exceptions, though of course the behavior is different.

The TRAP is more in line with the general definition of a SWI:

Software interrupt is an interrupt generated within a processor by executing an instruction. Software interrupts are often used to implement system calls because they implement a subroutine call with a CPU ring level change.

Technically using the "INTC Force Interrupt Register (INTC_FRC)" is software causing a hardware interrupt. 

I would not speculate as to what to OP intended, but I think now the difference is clear.

[TomE]

JimDon wrote:

> Software interrupt is an interrupt generated within a processor by executing an instruction. Software interrupts

> are often used to implement system calls because they implement a subroutine call with a CPU ring level change.

When I quote from Wikipedia I usually include the reference - it makes it sound more authoritative than "just something I said" :smileyhappy:

http://en.wikipedia.org/wiki/Software_interrupt#Overview

> I would not speculate as to what to OP intended,

I'd like to ask the original poster what he was looking to use "Software Interrupts" for, and what CPU and in what Operating System he has seen them used before.

Tom

[TomE · Accepted solution]

If you look at the table of "Exception Vector Assignments" you'll see that apart from the Hardware interrupts you have a choice of causing:

1. Unimplemented line F Opcode
2. Unimplemented line A Opcode
3. Trap 0 - 15
4. Level 1 - 7 Software Interrupts

The "standard way" to cause a sort of software interrupt on the 68000 has been to use the TRAP instruction. There are 16 of these. Famously, the Macintosh OS abused the Line A Unimplemented Opcode. What that means is that there are no instructions with the hex value 0xAxxx. So there are 4096 separate "illegal instructions" in this set that can be used like 4096 different traps. All of these traps happen immediately, whereas you probably want a "Software Interrupt" that can be posted during a hardware interrupt service routine and then happen later when the CPU priority drops.

That's what the "Software Interrupts" are for. You cause one of these by setting a bit in the "INTC Force Interrupt Register (INTC_FRC)" in the Interrupt Controller. The Interrupt Service routine then has to clear the "Forcing bit".

Tom