Trace through IRQ?

[UtopiaTim]

Hi folks,

I'm using a JM60 (on the DemoJM board).

My code is a combination of C and assembly.

Entering into one of the modules,  the first instruction

sets the IRQIE bit in IRQSC (enables the interrupt function of IRQ).

The next couple of instructions do mundane housekeeping.

I set a breakpoint several instructions down from the Bit enable instruction,

expecting the IRQ service routine to do it's thing (there is an interrupt pending),

then come back & do stuff from where it left.

The IRQ service routine only has the RTI instruction in it...

The system goes really far in the weeds.  - I have to reload the code.

I haven't had any problems using either the I2C or Keyboard interrupts & tracing through

them, etc.

Was just wondering if I'm doing something wrong.

Thanks,

Tim

[JimDon]

Hard to say without seeing the code.
Did you reset the rtc in flag in the handler?
You need this in the handler:
 RTCSC |= 0x80;

[UtopiaTim]

HI Jim,

The RTC is an external I2C Maxim part, so I'm not using the RTC on the

JM60.

Wasn't sure if there was some reason that trying to use BDM/code warrior with

IRQ would give me some problems.

Thanks,

Tim

[bigmac]

Hello Tim,

I am not familiar with the JM60.  Does the BDM pin share tha same pin as IRQ.  If so, you cannot use the IRQ function whilst debugging.

Regards,

Mac

[UtopiaTim]

Hi Mac/all,

Still have an issue.

I have reduced the hardware to a switch on IRQ. (not debounced)

IRQMOD=0 and IRQEDG=0 (falling edge triggered only).

I set a breakpoint for the beginning of the IRQ ISR, and it stops as soon

as I press the switch.

I step through the code, and it never exits the ISR.  The IRQ line is high.

Here's the basic code:

void main(void) {

  asm {
     cli
     nop
here:
     nop
     bra here
  }

}

__interrupt void isrVirq(void){

  asm {
    nop
    pulh
    rti
  }
}

Ideas?

Thanks,

Tim

[UtopiaTim]

Hi All,

OK, I'm awake now.... gotta set IRQACK to clear the source!

All's well.

Tim

[JimDon]

That's what I was tring to say (except you said RTC).

99%  the time when the int handler goes into the weeds, it's cause you forgot to clear the source.
For some reason, PE does not add to that the handler either, so it is easy to forget.
Also the debugger really has no good way to identify this.

I guess  I was not clear as far as a general statement goes.
* You MUST always clear the interrupt in the handler, if nothing else. *
Well, as least this was enough pain for you  to think of it next time.

[UtopiaTim]

Thanks Jim,

hehe,  I'm having a lot of those 'remembering' episodes!!

It's been a while since I did an IRQ routine, and back then, there weren't any

flags to clear! (other than the I bit)

Got it now.

Tim

[bigmac]

Hello Tim,

I am not sure whether part of your problem, but I question the advisability of the code you have posted.  The ISR function is entered using the __interrupt designation, and then you exit the ISR using inline assembler.  You are really second guessing how the compiler handles the interrupt, and what may have been pushed onto the stack.  The best approach is to let the compiler handle the exit from the ISR function.  The following framework is suggested.

__interrupt void isrVirq(void)

{

  asm {

  /* Do ASM things */

  }

  /* Do other C things */

  /* Clear interrupt flag */
}

I seem to recall that, for some MCU, the external IRQ flag is automatically cleared when the vector is fetched.  Perhaps there are differences for different MCU types.

Regards,

Mac

[UtopiaTim]

Hi Mac,

Thanks for the tip!  That explains a lot.  (howcome CW adds the helpful PSHH & then

(with my rti) I had to supply the PULH)!

Took out the PULH & RTI, let it terminate with the }, and all is well.

I guess after so many years of assembly I wasn't used to something 'helping' me!!

Thanks again!

Tim

[JimDon]

What mac said is 100% correct.

Just to further explain, the hardware does NOT save register H on interrupt, I believe for 05 compatibility.
So, if you do anything in the interrupt, in the compiler will save register H on the stack (apparently even if it did not need to) and restore it.
In th future, you can use the 'disassemble'  function  on the right click menu to view the code that compiler generated. It's a great cheat for writing assembly language. Also, you may decide to stop using assembly language once you better understand how the compiler does things, as using asm makes it harder to switch processors.
The for the few instructions that require asm language, there are provided macros that port to all Flexis family products. In a few months when the CF V1 USB chips come out, you may decide to move.

Processor Expert is quite good at moving a project from 08 to CF, but it can't do much about asm code.

If you generate all your I/O with Processor Expert, it can move you from 08 to Flexis with like 5 clicks. There is a demo that comes with the DEMOQE board that does just that. However, except for the vector table most i/o code will port either way.

Code:
Didn't really need to save it, but it did.

   60:  volatile char data;       61:  __interrupt void isrVirq(void)   62:  {  0000 8b       [2]             PSHH  // the hardware doe NOT save this.   63:       64:    data = 1;   0001 a601     [2]             LDA   #1      0003 c70000   [4]             STA   data   65:    asm {   66:     67:    }   68:    /* Clear interrupt flag */   69:  }  0006 8a       [3]             PULH    0007 80       [9]             RTI      70:  

 

[UtopiaTim]

Hi Mac,

I found it.

I wasn't paying attention to the assembly code window....

Looks like a PSHH is automatically inserted in the code by

Codewarrior (I guess).  I didn't do a PULH before the RTI, so the stack

was wrong. 

Thanks again!

Tim