• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Subscribers 33 subscribers
  • Views 1912 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

ISR firing all the time (using FreeRTOS)

george dorian
Intellectual 940 points
Other Parts Discussed in Thread: TM4C123GH6PM

OK, I give up.  I've been working this problem on-and-off all week.

I'm leaning Code Composer Studio and FreeRTOS.  I'm going through the FreeRTOS "A practical guide".  But I'm not sure if ether that is my problem.  I started out writing some code to learn passing semaphores.  I wrote an interrupt ISR and handler, but the ISR kept firing constantly, so I took out the semaphore and remarked out the handler.  So not it's just an ISR that increments and global variable.  But the ISR still keeps firing constantly.  I'm using the $12 launch pad board and the ISR is coded to fire when switch number 1 is pressed.  But it still fires all the time.

This is the set up code for the ISR:

//

//Enable the GPIO port F for LEDs.

 ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOF); //Enable the GPIO port F.

ROM_GPIOPinTypeGPIOOutput(GPIO_PORTF_BASE, RED_LED|BLUE_LED|GREEN_LED); //Port F for output. Pin 1 is red LED, pin 2 is blue LED, pin 3 is green LED.

ROM_GPIOPinWrite(GPIO_PORTF_BASE, RED_LED|BLUE_LED|GREEN_LED, false); //Clear LEDs.

// ROM_GPIOPinTypeGPIOInput(GPIO_PORTF_BASE, GPIO_PIN_4); //Port F pin 4 for input.

ROM_GPIODirModeSet(GPIO_PORTF_BASE, GPIO_PIN_4, GPIO_DIR_MODE_IN);

ROM_GPIOPadConfigSet(GPIO_PORTF_BASE, GPIO_PIN_4, GPIO_STRENGTH_2MA, GPIO_PIN_TYPE_STD_WPU);

ROM_GPIOIntTypeSet(GPIO_PORTF_BASE, GPIO_PIN_4, GPIO_FALLING_EDGE);

ROM_IntPrioritySet(INT_GPIOF_TM4C123, 0x40); //Set to interupt priority 2. 1 is higher then 2.

// ROM_IntPrioritySet(INT_GPIOF, 0x20); //Set to interupt priority 1. 1 is higher then 2.

GPIOIntEnable(GPIO_PORTF_BASE, GPIO_INT_PIN_4);

ROM_IntEnable(INT_GPIOF_TM4C123);

// ROM_IntEnable(INT_GPIOF);

This is the ISR code:

//*****************************************************************************

//

// ISR for switch 1

//

//*****************************************************************************

void ISR_Switch1(void)

{

// while(1);

/*

portBASE_TYPE xHigherPriorityTaskWoken = pdFALSE;

xSemaphoreGiveFromISR(SwitchISRSemaphore, &xHigherPriorityTaskWoken);

portEND_SWITCHING_ISR(xHigherPriorityTaskWoken);

*/

ROM_GPIOPinWrite(GPIO_PORTF_BASE, RED_LED, RED_LED); //Turn on red LEDClear LEDs.

ROM_SysCtlDelay(10000); //SysCtlDelayDelay loop takes 3 cycles per loop.

ROM_GPIOPinWrite(GPIO_PORTF_BASE, RED_LED, false); //Clear LEDs.

// redLEDdelay = redLEDdelay + 1000;

}

 

  • 0
    TI__Guru**** 244400 points
    Hello George,

    The GPIO Interrupt is not being cleared. You have to use the GPIOIntClear API to clear the Interrupt Sticky bit.

    Regards
    Amit
  • 0
    Guru 27285 points

    george dorian said:

    ROM_SysCtlDelay(10000); //SysCtlDelayDelay loop takes 3 cycles per loop.

     First problem was catch by Amit, about wait by delay loop this is a worst mode to be absolutely deprecated also if it can work!!! Use a timer instead or move to main loop fired by a semaphore I see you where experimenting with is more better.

     This to avoid long interrupt service not only behave bad on superloop application but drive to unreliable task execution when an OS is installed or very hard to diagnose malfunctioning.

  • 0 in reply to Amit Ashara
    Expert 1635 points

    Indeed, and another thing to consider is the switch bounce, you'll have to deal with that also, or else you'll fire the input ISR multiple times...

    You can do the debouncing with hardware(R/C), or in the software.

    If your main goal is to wait for switch input, but it's not that time critical, I would not use an ISR, but just poll the switch input in the main loop. You can do the debouncing using a timer, or simply by using a variable which counts a preset number of 'button pressed' loops(when polling), which then changes the state to 'Button Is Pressed', for example.

    There's an example for debouncing switches, which is called 'buttons.c' in the 'drivers' directory.

  • 0 in reply to marc_rir
    Guru 27285 points

    marc_rir said:
    There's an example for debouncing switches, which is called 'buttons.c' in the 'drivers' directory.

     Hi Mark, did you grasped how to use and how it work?

     I never seen again but first time scared me a lot... About how this can be an example.

     I used a timer to sample external value and debounce myself as I learn many time ago.

     Same was for HTTP server interrupt driven as Ethernet example.. It scared me from usage and I finally found TIRTOS api where close to Linux network call leaving me the chance to reuse code quite as is with few conditional compile.

  • 0 in reply to Amit Ashara
    Intellectual 940 points

    Looks like that did it. However...

    I could not find any information about clearing interrupts in the TivaWare™ Peripheral Driver Library user guide.  The "interrupt.c" example code does not seem to that function.  On page 189 of my Yio book it says "Once the processor enters the exception handler, the pending status is cleared automatically." 

    So I'm still confused.

    Thanks for you help.  George  

  • 0 in reply to george dorian
    Guru 20670 points
    Hi george,

    I don't know which part you are using but in the tm4c123gh6pm datasheet it says that in "3.1.2 Nested Vectored Interrupt Controller (NVIC)", more specifically in "3.1.2.2 Hardware and Software Control of Interrupts"

    I have not read that book but read a little harder. I am sure it's referring to something like the system tick that does not need the interrupt to be cleared, i actually don't know if there is any other peripheral that does not need the flag to be cleared besides the system tick interrupt
  • 0 in reply to george dorian
    Guru 47900 points

    george dorian said:
    page 189 of my Yio book it says "Once the processor enters the exception handler

    You may have read bit too fast and/or uncritically:

    a) Joseph Yiu is book's author

    b) Quote you reference targets (only) those peripherals which generate IRQs, "in the form of pulses." 

    KISS dictates that you build familiarity w/basic MCU features/functions - prior to employing RTOS.  Too much - too soon - clouds the issue, "Why your program, "Does not Work."

    Review of multiple examples w/in driver library most always includes the "clearing" of the specific interrupt w/in it's handler.

  • 0 in reply to cb1
    Intellectual 940 points

    I feel that both you have points. The one doc I didn't think to read is the data book for that MPU!
    I'm actually reading a number of things the driver manual, FreeRTOS manual, sometimes CCS and IAR manuals, Yiu's book, the MPU manual for a few Tiva parts that I'm using and a few other things. It's a lot of "tasking". And most of those documents are more of references (which don't really teach). I do wish there was a friendly book, preferably written by a teacher, to actually teach new comers like me all this stuff. Seems to me that this would be a very good demonstration of TI's customer consideration. I would assume this would also attract engineers, new to ARM, to TI's products.
    George

  • 0 in reply to george dorian
    Guru 47900 points
    May I suggest your promotion of "KISS?" Your goals are all valid - but (clearly) you're doing too much - and way too soon!

    You speak of teachers - imply education - but are not there "prerequisites" - required prior to taking more advanced courses? Your way - too much/too soon - would challenge even the best/brightest "teachers" - even those of this hallowed vendor.

    One "dragon" (or windmill) at a time - par for most here. (and surely for this reporter...) Bon chance, mon ami.