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.

TM4C123BH6PZI, PORT D, PIN 7, GPIO Input: Edge Interrupt does not work

Hi All,

Here is signal which comes to PORT D, Pin 7 of the MCU

Here is code for MCU/GPIO setup:

main(void) 
  ROM_FPULazyStackingEnable();
  ROM_FPULazyStackingEnable();
//on-board OSC 25MHz, MCU - 80MHz
  ROM_SysCtlClockSet(SYSCTL_SYSDIV_2_5 | SYSCTL_USE_PLL | SYSCTL_XTAL_25MHZ | SYSCTL_OSC_MAIN);

  ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOD);// Enable port D

  ROM_GPIOPinTypeGPIOInput(GPIO_PORTD_BASE, GPIO_PIN_7);


  GPIOPadConfigSet    ( GPIO_PORTD_BASE,// Enable weak pullup resistor for PD7
                          GPIO_PIN_7,
                          GPIO_STRENGTH_2MA,
                          GPIO_PIN_TYPE_STD_WPU);

  GPIOIntDisable       (GPIO_PORTD_BASE, // Disable interrupt
                          GPIO_PIN_7);

  GPIOIntClear        (GPIO_PORTD_BASE, // Clear pending interrupts
                         GPIO_PIN_7);

  GPIOIntRegister     (GPIO_PORTD_BASE, // Register our handler function for port of D channel
                         IntDRDY);

  GPIOIntTypeSet      (GPIO_PORTD_BASE, // Configure  for falling edge trigger
                         GPIO_PIN_7,
                         GPIO_BOTH_EDGES);//GPIO_LOW_LEVEL);//GPIO_BOTH_EDGES);

  GPIOIntEnable       (GPIO_PORTD_BASE, // Enable interrupt for the port
                         GPIO_PIN_7);

while(1){};
}





and here is interrupt handler

void
IntDRDY(void){

      uint32_t ui32Value;
      ui32Value = GPIOIntStatus(GPIO_PORTD_BASE, true);

      if (GPIOIntStatus(GPIO_PORTD_BASE, false) & GPIO_PIN_7) { //check


        //GREEN LED on
        ROM_GPIOPinWrite(GPIO_PORTA_BASE, GPIO_PIN_2, GPIO_PIN_2);


        GPIOIntClear(GPIO_PORTD_BASE, GPIO_PIN_7);  // Clear interrupt flag (!)
                                                    // if not clear interrupt call continuosly
    }



}

the interrupt handler executes only when GPIO_LOW_LEVEL is set,  GPIO_FALLING_EDGE/GPIO_RISING_EDGE/GPIO_BOTH_EDGES/GPIO_HIGH_LEVEL do not work.

What could be wrong?

Thanks for any advice!

  • Hello Vasiliy,

    Please have a look at the post

    http://e2e.ti.com/support/microcontrollers/tiva_arm/f/908/t/374640

    Regards
    Amit
  • Thanks! It works now!
  • Amit Ashara said:
    Please have a look at the post

    Indeed - and that "look" after some "hunt" does reveal a solution.

    Yet - as this poster has so acutely ID'ed his issue w/in his subject/title - does it not make sense to state (quite clearly)

    TM4C123 and LX4F users - Do note that 2 pins - "PF0 & PD7" default into a special mode (NMI) and require a special procedure to use as (normal) GPIO!  They will not behave as desired/expected until you comply w/directions w/in linked, forum thread.

    Yes it's "quick/easy" to simply "link" - yet the one simple sentence of "explanation" conveys far more care - and meaning - saving hours of lost user effort...

    And as (so long) past (repeatedly) stated - should not this, "Default to NMI" behavior be re-visited - and in light of the vast majority of users NOT seeking, nor understanding the full implications of such NMI - be changed to the far more normal/customary, "Default to GPIO?"  

    Seems an obvious, "No brainer" even though (and especially so) NIH...  

    One (really many) must ask, "Why has this "user horror" been allowed to continue - for over 2 years (now)?  Sticky posts have proved ineffective - and they're not even titled correctly.  (far too general to gain note of "distressed" users)

    Yes - a change to the silicon does cause some pain/suffering - yet revisions do (normally) occur - and such would be a most appropriate inclusion...

  • Yes, I agree with you and add here work around for next readers. To solve issue just add extra code after peripheral enable and before irq init:

    //
    // unlock Port D, Pin 7 (DRDY): http://e2e.ti.com/support/microcontrollers/tiva_arm/f/908/t/374640
    //
    HWREG(ADC_RST_DRDY_PORT+GPIO_O_LOCK) = GPIO_LOCK_KEY;
    HWREG(ADC_RST_DRDY_PORT+GPIO_O_CR) |= ADC_DRDY_PIN;
  • Good for you, Vasiliy - you've now (effectively) closed the loop on your thread - good job - thank you.  

    Again - you simply "nailed" the subject/title of your post - your care & effort clearly shine...

    Pity though - as good as this thread is - it will (surely/quickly) rotate into forum oblivion - to be seen (only) by those aware enough - and motivated enough - to engage forum search.  

    Proper "warning" Page ONE of MCU manuals - or a reconfig of silicon - provides real (and far more appropriate) solution.  

  • Hello cb1,

    WONDERING: Even with a proper warning in the MCU manual, would it still be a 100% guarantee that the issue is well avoided and in-time corrected? You and me may read the manual... But not everyone...

    Silicon Rev may solve it but break the application code for some of us with the fact that it was locked so I need not worry but now with a unlocked pin, I have to field update new systems sent out...

    Trying to arrive at the best coverage solution... Advise most welcome.

    Regards
    Amit
  • Amit Ashara said:
    You and me may read the manual... But not everyone...

     Ad some others too ;) but manual is HUGE and when you experiment something to improve learning curve you are hitten from this issue before arriving to proper chapter.

     If in first page read before all, yes I was protected in advance. This processor is forever too complex and after long long time I begin now to know surely not in deep.

    Amit Ashara said:
    Silicon Rev may solve it but break the application code for some of us with the fact that it was locked so I need not worry but now with a unlocked pin, I have to field update new systems sent out...

     If it default to GPIO require just VERY FEW application to be corrected and with new silicon revision can also change processor code so it never can be exchanged to.. announce discontinuation then after SOME LONG time processor can be NRND.

     Who use in non NMI can use as if not changed and who used NMI can be alerted, again I see NMI is not simple ready but need some processing, this is enough to cover a new silicon without these threat.

  • Roberto Romano said:
    If it default to GPIO require just VERY FEW application to be corrected

    Hi Amit & Roberto,

    Amit - as Roberto (so well) states above - I'd peg 90% (or higher) of users to much prefer, "GPIO as default."  In fact - we've over 50 LMI/TI ARM MCU clients - I can only recall ONE (and they just once) having employed NMI.  Thus - management's past decision (default to NMI) - is in clear violation of, "80-20" rule!  (do for the benefit of vast majority of users)  

    We note - that past decision (NMI as default) - has never been explained - nor justified - why is that?  (it clearly has wreaked great pain/suffering - has it not?) Who (really) has benefited?   (perhaps ONE key client (my guess) but at what cost to your majority?)   (yet has allowed one here to achieve (largely unearned/repetitive) forum status...)

    Surely - those sophisticated enough to understand - and think (mistakenly, I now believe - thanks to Robert) that they NEED NMI - can make the time/effort to read - and master the, "How."

    I fear that you are falling into the trap, "There is no 100% perfect Solution" - therefor let's do nothing!  That's just wrong - and I can assure you - my past firm went "Public" w/out 100% perfection - yet never did we leave a, "Festering Sore" because a (mythical) "perfect solution" could not be found/created!

    Change in the silicon is best - Page ONE Warning second best.  We were taught - in going public - PARADE your weaknesses - not HIDE them!  Yes your firm is giant - but doubtful that size resulted from "practices" (I use term loosely) presently in play.  (i.e. "bandaid solutions, respond (a la Exosite) when/if ready, and (apparently) "hide weaknesses" (NO Page 1 warnings! - at the cost of client loss/frustration...")

    From my past "tour of duty" at similarly sized (large) semi firm - I can tell you that such "long, festering sores" are NOT how you, "Outperform your market!"

  • Hello cb1, Roberto

    Point taken. Haven't seen much emphasis on NMI (one post I recall in the last week) as default pin but seen a larger set of posts on pin not working as GPIO... Thanks..

    Regards
    Amit
  • Amit Ashara said:
    Haven't seen much emphasis on NMI ... as default pin... but a larger set of posts on pin not working as GPIO

    To be far more in line w/forum (and our MCU clients') reality - let the record clearly reflect not (just) a "larger" but a "VASTLY LARGER" set of failures reaped by those 2 pins defaulting away from (standard) GPIO default.  Being (somewhat) active here - I'd place that ratio at (easily & conservatively) 100:1!

    We really shouldn't "run from this known problem" (pretend it doesn't exist) and employ (yet another) ineffectual "band-aid" - should we?  

    Have not your client users suffered enough?  

    And (always unexplained) to what purpose was such a hurtful decision made - and permitted to continue - for so long?