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

Thank you! 

That does the trick!

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..."

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.

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..."

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!

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...")

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.