• State
  • Locked Locked
  • Replies 9 replies
  • Subscribers 31 subscribers
  • Views 996 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.

TM4C123GH6PM timer0 and timer1 interrupt problem

Mark Anthony Cabilo
Prodigy 205 points
Other Parts Discussed in Thread: TM4C123GH6PM

I am new in this forum and I have been using Tiva for a few months. I am working on a project that collects data at a rate of 15360 samples per second and executes such data collection once every minute. I used two timers in Tiva Launchpad (TM4C123GH6PM): Timer0A and Timer1A.

Timer0A is triggered every 1/15360s (TIMER0->TAILR = 0x00000412) and Timer1A is triggered every second (TIMER1->TAILR = 0x00F42400) using the default 16MHz clock. I also declared interrupt routine handlers (TIMER0A_Handler(void) and TIMER1A_Handler(void)) and included the IRQns in the vector table (number 19 and number 21) in the cstartup_M file.


At first, both were running but after debugging for the second time, the code is still running but the interrupts are never triggered. Did I miss something?]

These are the interrupts that were never triggered during second debug run:

This is the part of register initialization for both timers:

These are the lines where I start the interrupt routines and the clocks:

Thanks in advance!!!

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

    When you halt the code the second time does the CPU show that it is executing the main code and not in some fault condition?

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Prodigy 205 points

    Hi Amit,


    Yes. It is executing the main code (other initializations I did such as LEDs and UART are working fine). I figured out earlier today that I missed an interrupt mask for the first timer and it affected the second one too. Now they are both running fine.

    Right now, I'm facing a different problem. Maybe you could still help me. *laughs*.


    Technically, I am using three interrupts in my project. Timer0A, Timer 1A, and GPIOE interrupts. Now, The two timers are working fine. However, I find false triggering for my GPIOE level-dependent interrupt.

    This is the interrupt handler. The extflag is an uint8_t variable and FLAG_FULL is a simple macro that will be used in the actual function when the interrupt is trigggered:

    In included the interrupt handler in the interrupt table (#4 see below) and the configuration of Port E is shown following:

    Please understand that the GPIOE is also used for my ADC  (PE1 and PE2) and that is what timer0A (sampling rate speed clock) is used for. I enabled portE and configured PE1 and PE2 earlier before the lines of code shown above.

    These are the lines where I enabled the interrupt routine:

    The result after compiling and uploading these codes is that the Tiva seems to be constantly triggered and will not move past the function where extflag variable (shown earlier in this discussion) and its value is used. So I assumed that the interrupt on PE3 is always triggered. However, I only allowed a pulse to be input to the pin. Did I miss something again?

    Thank you very much in advance.

  • 0 in reply to Mark Anthony Cabilo
    TI__Guru**** 244400 points
    Hello Mark,

    I could not see any code in your last post either. In level triggered mode, as long as the level is maintained the interrupt shall fire. Rather than using a level sensitive interrupt why can't edge sensitive with GPIOPinRead to make sure that the level is high be used instead?

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Guru 117855 points

    And - if I may - have you carefully monitored & measured that "pulse" (@ the MCU) to insure that it (really) reaches its target MCU pin? If the pin is floating and/or your "pulse" proves insufficient (level wise) you'll incur trouble. 

    Amit's direction to "Edge rather than Level" is the more conventional "way to go" - although still vulnerable to "floating and/or high Z" MCU inputs... And - have you properly terminated the remainder of Port E's pins? (always unwise to leave a GPIO pin floating)

    KISS (appears) absent w/in your (all at once) methodology.   When multiple functions & interrupts "dwell" - troubleshooting is made far more complex & time consuming.   One function exercise - till "test/verify" - and only then the methodical introduction of "Next function" (and its test/verify) proves a highly successful m.o..  (modus operandi)

  • 0 in reply to Amit Ashara
    Prodigy 205 points
    Just to be sure, you are suggesting to use edge-triggered interrupt right? Okay, I'll try that. I'll tell you if it finally works.
  • 0 in reply to cb1_mobile
    Prodigy 205 points
    Hi cb1_mobile,

    I believe my pins are properly terminated. Anyways, I'm quite unfamiliar with KISS to be honest (the KISS I'm familiar with is an FFT library and the other one *laughs*). But if I understood your point well, yes, I implemented the code in the modular approach. I ensure one module (say a single timer - timer0A - interrupt) is running first before moving on to the next (addition of timer1A). Finally, I am stuck with an addition of another interrupt, the GPIO pin.

    Nonetheless, I'll see to it that your suggestion of checking floating/high Z MCU inputs and proper terminations is done just to be sure.

    Thanks.
  • 0 in reply to Mark Anthony Cabilo
    TI__Guru**** 244400 points
    Hello Mark.

    Yes, that is correct.

    Regards
    Amit
  • 0 in reply to Mark Anthony Cabilo
    Guru 117855 points
    You've understood very well - and indeed that, "One small MCU battle at a time - till victory (i.e. test/verify) - and only then onto (next battle)" well defines KISS.
    Too much - too soon - adds complexity - sometimes exponentially. Slow, steady, test/verified - most always - achieves best results in the shortest time...
  • 0
    Prodigy 205 points
    This problem has been solved. The problem was missing the interrupt call in the startup file.