Author Topic: IRQ1 problems  (Read 8768 times)

Offline ewan

  • Newbie
  • *
  • Posts: 43
    • View Profile
IRQ1 problems
« on: November 01, 2008, 07:12:50 PM »
I have an SPI device with which I can communicate properly. It returns an interrupt (rising edge) which is connected to IRQ1 in the 80 pin package. The code is
Code: [Select]
void fnRC531 (TTASKTABLE *)
{
  volatile unsigned char          result, result2;
  static char                     FirstTime = TRUE;
  INTERRUPT_SETUP                 interrupt_setup;
 
  if (FirstTime == TRUE)
  {
    FirstTime = FALSE;

    interrupt_setup.int_type     = PORT_INTERRUPT;                       // identifier when configuring {25} - always initialise
    interrupt_setup.int_handler  = RC531_IRQ_OnInterrupt;                // handling function
    interrupt_setup.int_priority = (INTERRUPT_LEVEL_1);                  // interrupt priority level (this can not be modified for IRQ1..IRQ7 so the value is not really relevant)
    interrupt_setup.int_port_bit = 1;                                    // The IRQ input connected
    interrupt_setup.int_port_sense = IRQ_RISING_EDGE;                    // Interrupt on this edge
    fnConfigureInterrupt((void *)&interrupt_setup);                      // configure test interrupt
  }
 
  OpenCard();
 
  ReadCard();
 
  uTaskerStateChange(TASK_RC531, UTASKER_SUSPENDED);  // run task only once for now
}
I have a breakpoint set as follows
Code: [Select]
/*
** ===================================================================
**     Event       :  RC531_IRQ_OnInterrupt (module Events)
**
**     Description :
**         This event is called when an active signal edge/level has
**         occurred.
**     Parameters  : None
**     Returns     : Nothing
** ===================================================================
*/
void RC531_IRQ_OnInterrupt(void)
{
  RC531_IRQ_Disable();         // <--- the breakpoint is at the start of this line
  uEnable_Interrupt();
  SingleResponseIsr();
  RC531_IRQ_Enable();
}
When I run the program it never reaches the breakpoint. Instead it goes here
Code: [Select]
// default interrupt handler - and undefined interrupts will arrive here
//
static __interrupt__ void undef_int(void)
{
    while (1) {}                                                         // wait here and analyse with debugger....
}
If I comment out the interrupt_setup stuff the program does not work, of course, but I don't get the bum interrupt.
Where am I making a mistake?

Regards,

Ewan.

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3234
    • View Profile
    • uTasker
Re: IRQ1 problems
« Reply #1 on: November 02, 2008, 12:06:33 AM »
Hi Ewan

I see no problems with the configuration code.

1. Is the interrupt (rising edge on IRQ1) occurring or not? Or is it crashing even without the interrupt taking place?

2. I am not absolutely sure whether the interrupt routine is being called or not. Assuming that you are debugging with CW it is sometimes difficult to get a break point on a certain line of code (due to optimisation). I would suggest putting it deeper down - in the IRQ routine itself. This is a static __interrupt__ void _irq1_handler(void) in M5223x.c

If you get here it means that the interrupt is firing and you can step to see whether the call back is being dispatched correctly or not.

3. The only reason that I can think of that will cause the interrupt to fail before getting to _irq1_handler(void) is if the vector table in SRAM has been corrupted. This is however very unlikely.

4. Note that the interrupt handler (in your case RC531_IRQ_OnInterrupt()) is a call back from within the IRQ interrupt routine itself. Interrupts are disabled on entry. You have to be a little careful what is actually performed in the interrupt routine, but I don't know whether this is an issue at the moment.

5. If you need to debug the cause of a particular exception you can also use the following guide as help:
http://www.utasker.com/forum/index.php?topic=123.msg468#msg468

Regards

Mark

Offline ewan

  • Newbie
  • *
  • Posts: 43
    • View Profile
Re: IRQ1 problems
« Reply #2 on: November 02, 2008, 06:04:24 PM »
Mark,

I can confirm that if I comment out fnConfigureInterrupt the problem does not occur. The device then raises its IRQ line as expected (but with no response from the CPU). When left as shown above, the failure takes place before the device sets its IRQ. I will now read the guide you suggested and dig deeper.

Thanks,

Ewan.

Offline ewan

  • Newbie
  • *
  • Posts: 43
    • View Profile
Re: IRQ1 problems
« Reply #3 on: November 02, 2008, 09:46:33 PM »
The problem was that there were other places in "application.c" that were setting the same interrupt. I commented them out and the new IRQ1 works fine. Of course, I now have a whole new set of problems not associated with the interrupt.

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3234
    • View Profile
    • uTasker
Re: IRQ1 problems
« Reply #4 on: November 02, 2008, 10:44:46 PM »
Ewan

OK. #define IRQ_TEST was seemingly set - I assume you have now commented it out.

Regards

Mark

Offline ewan

  • Newbie
  • *
  • Posts: 43
    • View Profile
Re: IRQ1 problems
« Reply #5 on: November 02, 2008, 11:13:00 PM »
Indeed, Mark.

Thanks,

Ewan.