• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Subscribers 31 subscribers
  • Views 853 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.

CCS/TM4C129ENCPDT: Systick Timer Interrupt not triggered on custom board

Hau Tran
Intellectual 615 points
Part Number: TM4C129ENCPDT
Other Parts Discussed in Thread: TM4C1294NCPDT,

Tool/software: Code Composer Studio

Hello,

I have been develop my project on the TIVA 1294 LaunchPad (TM4C1294NCPDT) and the application was working fine. I then developed a custom board that uses TM4C129ENCPDT. I was able to load the program onto the new board and turn on/off some GPIOs. I then tried the delay function which is getting the tick data from interrupt handler function from SYSTICK and the interrupt doesn't get triggered.

I tried to create the same project but use the start up file for TIVA 1294LaunchPad, using the same program and the delay function worked on the LaunchPad (I check it by blinking an LED), the tick was increasing by the systick interrupt handler.

I went further by implementing a timer with its own interrupt when reached 0 and the interrupt didn't trigger either.

I have no clue what is wrong with my custom board, has anyone encountered this problem? 

I attached the project for my custom board along with the post, please feel free to take a look. 

Thanks,

AlexDAQonTiva.zip

  • 0
    TI__Guru*** 135355 points

    Hello Hau,

    You need the following call to enable interrupts at a processor level in addition to what you have done on a peripheral level:

    IntMasterEnable();

    What is likely happening with the LaunchPad is that the processor level interrupts have already been enabled by a prior program and did not get disabled, so you aren't noticing the issue there.

  • 0 in reply to Ralph Jacobi
    Intellectual 615 points

    Thank you! 

    That does the trick!

  • 0 in reply to Ralph Jacobi
    Guru 117855 points

    Greetings Ralph,

    Good job - you (just) beat young staff here to the punch!

    We've two comments which likely will "resolve" this (repeating) issue - while adding value & residual power to this thread:   (and beyond)

    • we've long noted that 'frequently' our peripheral interrupts succeed - even when we fail to include "IntMasterEnable()."     You've (perhaps) just identified the reason behind this (i.e. "IntMasterEnable()" (may) have a 'sticky' property - which leads users (as happened here) to neglect its call.    (And we've never/ever observed this (valuable) "Ralph Find" being elsewhere noted!)     Staff believes this important guidance should be included w/in the API Update.
    • the code examples w/in the "Peripheral Driver User Guide" (never) include the call to,  "IntMasterEnable()."    Should not this fact - at minimum - receive some mention w/in (each example) - ideally atop the example code?    

    Here's the Systick example - clearly illustrating staff's claim:

    Our poster here did 'everything right' - yet the Guiding Examples (ALL of them!) neglect this key requirement - and "Ralph's Sticky Factor" explains why 'Success' may be temporary!     Simple addition of, "Insure that a call to,  "IntMasterEnable()" (not shown in the example code, below) must appear (somewhere w/in your code) if & when interrupts are deployed..."

  • 0 in reply to cb1_mobile
    TI__Guru*** 135355 points

    Hello cb1,

    I'll discuss w/ Bob & Charles where we could improve this, but the examples that are lacking it don't use interrupts at all which is why the call is excluded in them. Any TivaWare example that uses interrupts does show the IntMasterEnable() API being called.

  • 0 in reply to Ralph Jacobi
    Guru 117855 points

    Hello Ralph,

    Do note - staff's wording, " "Insure that a call to,  "IntMasterEnable()" (not shown in the example code, below) must appear (somewhere w/in your code) if & when interrupts are deployed..." provides for the situation you've noted.

    Again - this poster "Fell victim" to "Missing this call" - and he's far from alone in falling to this trap.    Proper written guidance - even strengthened by employing emphasis - would "Free your group so that the promised/teased API Updates - may arrive w/out further delay..."

  • 0 in reply to cb1_mobile
    TI__Guru*** 135355 points

    Hello cb1,

    Ah, now I see what you are suggesting more clearly. Sorry, been a long day and I didn't register that as a suggestion to quote in the document but instead thought it was a statement of 'if interrupts are used in the example, IntMasterEnable() should appear in the programming example'. ...Much clearer now!

  • 0 in reply to Ralph Jacobi
    Guru 117855 points

    Hello Ralph,

    Thank you - your follow-up better represents your (usual) keen MCU guidance.

    Again - it is possible that you are the first (or surely among the earliest) to have identified the (possible) 'Sticky' nature of,  "IntMasterEnable()!"    Without your recognition & presentation here (i.e. sticky nature of that call) - the importance of this call is likely to be diminished - as users succeed while w/in debug yet fail when, 'run for real.'    

    As a small, Tech Biz owner it is (always) important to, "Recognize & then properly: promote, deploy, & exploit" (i.e. latch onto!) sound ideas & findings - so that they may be used repeatedly!

    Team & I hope that your "API Enhancement" team will avoid "Limiting your good 'find/discovery' to a "One & Only One" - presented (only) here!     (And w/in a day or two - rotating off into "forum oblivion...")

  • 0 in reply to cb1_mobile
    TI__Guru*** 135355 points

    Hi cb1,

    Maybe in a sense of semantics of that API specifically... but in reality you, twelve12pm, and Bruno had a long discussion on the topic before too... https://e2e.ti.com/support/microcontrollers/other/f/908/p/605306/2227949#2227949

    From my understanding, IntMasterEnable adjusts the value of PRIMASK, so that would be a far earlier recognition of this interesting quirk that - from what I read in your postings - seems to be traced back to ARM M4F implementation.