topic Re: MCF52235EVB - Help with Interrupts in ColdFire/68K Microcontrollers and Processors

MCF52235EVB - Help with Interrupts

ornini — Wed, 11 Jul 2007 21:32:05 GMT

Hi guys,

I know I've already asked it, but this is driving me crazy - I can't make it the INTERRUPT (using SW3 - IRQ1 on the EVB) works.

I'm newbie, but I did everthing by the book, and with your help (THANKS again Kremer and MARK) - and I'm sure it is something stupid, basic thing that I miss.

I really need your help. Please take a look:

This is the main.c:

Code:

/* * File:  main.c * Purpose:  sample program * */#include <stdio.h>//#include "include\m52235evb.h"#include "common.h" unsigned char stop=0;void delay(int t_end){ int i,j; for (i=0;i<t_end;i++) {  for(j=0;j<10000;j++);  }}int main(){ unsigned char i;    MCF_GPIO_PNQPAR = (0 | MCF_GPIO_PNQPAR_IRQ1_IRQ1);     // set interrupt function on port NQ MCF_EPORT_EPPAR0 = (0 | MCF_EPORT_EPPAR_EPPA1_RISING); // IRQ1 interrupt - I TRIED RISING, FALLING, LEVEL, BOTH MCF_EPORT_EPIER0 = (0 | MCF_EPORT_EPIER_EPIE1);        // enable IRQ1 MCF_INTC0_ICR1 =  (MCF_INTC_ICR_IL(4) | MCF_INTC_ICR_IP(4));  // set interrupt level and priority MCF_INTC0_IMRL &= ~(0 | MCF_INTC_IMRL_MASK1                       | MCF_INTC_IMRL_MASKALL); // Unmask all interrupts Leds_Init();  while(1)   // LOOP that display running LEDs on the board {  for (i=0; i<0x10; i++)  {   board_led_display(i);   delay(100);   if (stop==1)  // SHOULD STOP THE PROGRAM when I press SW3    {    return;   }  }   }  return 0;}__interrupt__ void irq_1_isr(void){ while (!(MCF_EPORT_EPPDR0 & MCF_EPORT_EPPDR_EPPD1)) {}; // SHOULD STOP THE PROGRAM when I press SW3  stop=1; MCF_EPORT_EPFR0 = (uint8)(MCF_EPORT_EPFR0 | MCF_EPORT_EPFR_EPF1);}

and this is what I've added/Changed it the mcf52235_vectors.s :

Code:

  .  .  .#define _irq_handler      irq_handler#define _irq_1_isr      irq_1_isr // added this line  .  .  ..extern _irq_handler.extern _irq_1_isr   // added this line  .  .  .//vector41: .long _irq1_handler // Changed this linevector41: .long _irq_1_isr  // added this line  .  .  .

Message Edited by ornini on 2007-07-11 03:40 PM

Re: MCF52235EVB - Help with Interrupts

SimonMarsden_de — Wed, 11 Jul 2007 23:50:03 GMT

Hi

Did you remember to drop the processor's interrupt fence (located in the Status Register, or SR)? This is set to 0x7 on boot up, masking all interrupts.

You need something like:

    asm {
        move.l   #0x00002000,d0
        move.w   d0,SR
    }

(Puts 0x2000 into the SR, thus setting the interrupt mask to 0 and enabling all interrupts).

Hope this helps

Simon

Re: MCF52235EVB - Help with Interrupts

ornini — Thu, 12 Jul 2007 22:47:17 GMT

Thank you very much Simon, you really helped me out.

Now the program do respond to the SW3 (IRQ1), but I get an error message when I press the switch.

"Exception vector name: Bus Error

PC where the exception happened: 0x205AE118"

Do you know what is it?

Thanks.

Re: MCF52235EVB - Help with Interrupts

mjbcswitzerland — Fri, 13 Jul 2007 05:42:16 GMT

Hi Ornini

The error that you are seeing is possibly due to the fact that you are returning from main when you detect that the button has been pressed.

Often the startup code is not designed for main to actually return. It may be implemented as a jump rather than a jump to subroutine (then there is no return address on the stack). Or it may simply have no code following the main call which leads to a crash.

Set a break point at the return line to be sure that it is really getting there and possibly toggle an LED rather than performing "return".

Regards

Mark

P.S. You should also have received a compiler warning since your return is not returning a value, although main is declared as int main(void). It is always important to look carefully at compiler warnings since they sometimes point out things that can really cause a program to fail.
In CodeWarrior you can configure the compiler to demain prototypes so that it will generate an error when it doesn't have the information to do full function checking. This should be activated since it can also avoid potential serious errors when call conventions do not match.

Message Edited by mjbcswitzerland on 2007-07-13 12:46 AM