• State Resolved
  • Locked Locked
  • Replies 22 replies
  • Subscribers 35 subscribers
  • Views 5790 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.

How to setup NMI for critical INT?

Gavin Lin1
Expert 1875 points
Other Parts Discussed in Thread: STRIKE

Hi 

I have one critical HW INT and plan to adapt to PD7 as NMI.

Is there any sample code to refer how to implement?

thanks

Gavin

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

    There is no example code for NMI. However to implement the NMI you would need to modify

    1. The NMI Handler code can be written in the main code
    2. The Interrupt Vector Map needs to be modified to have the function mapped in place of the default handler. Do make sure that the function is declared as an extern function
    3. Enable the GPIO PD7, GPIODEN register bit for Digital function.

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

    Amit Ashara said:
    Enable the GPIO PD7, GPIODEN register bit for Digital function.

    Hi Amit,

    Of course you're blameless in this (on-going) "NMI-hiccup" situation - but is it not strange - and inconsistent - that the default setting of NMI appears "incomplete?"  (that conclusion based upon the (seeming) necessity to attend to GPIODEN.)

    Would it not have been far simpler - and more proper - to default the NMI pin "all the way" into NMI "readiness" - and not leave yet another pitfall (GPIODEN) for (already) hapless users?

    As an aside - iirc - we once employed the NMI successfully w/in LX4F (may they rest in peace) and I can't recall, "jumping thru the GPIODEN hoop!"  Due to the (apparent) "incomplete default set-up" and our (long past) anecdotal finding - are you quite sure that GPIODEN must be tweaked to achieve NMI functionality?

  • 0 in reply to Amit Ashara
    Expert 1875 points

    Hi Amit

    About Step.3, you mean that enabling PD7 as interrupt pin and setting GPIODEN register only. 

    Do I get the wrong understanding?

    Do I need to unlock PD7?

    thanks

    Gavin

  • 0
    Guru 27665 points

    My first thought is. Are you really, really, really sure you need an NMI for this?  NMIs look attractive for high priority interrupts but they are a double edged sword with a really sharp blade.

    The Cortex interrupt structure allows for prioritizing interrupts. In every case I can think of for a HW interrupt you would bring in on an external interrupt line you would be better off reserving the highest priority (non-NMI) interrupt level for your HW interrupt. That gives you almost all of the benefits of an NMI with none of the hazards.  In my experience the additional benefits you get from an NMI are better obtained in another fashion in most cases.

    Robert

  • 0 in reply to Gavin Lin1
    TI__Guru**** 244400 points
    Hello Gavin,

    The step would be
    1. Unlock the Pin using the GPIOLOCK and then commit the bit using GPIOCR
    2. Configure the GPIOPCTL, GPIOPDR, GPIODEN and GPIOAFSEL.
    3. Please note that the NMI is detected on level high, so a Pull Down has been enabled.

    //
    // Unlock the Port-Pin and Set the CR bit for PD7
    //
    HWREG(GPIO_PORTD_BASE+GPIO_O_LOCK) = GPIO_LOCK_KEY;
    HWREG(GPIO_PORTD_BASE+GPIO_O_CR) |= GPIO_PIN_7;
    GPIOPinConfigure(GPIO_PD7_NMI);
    GPIOPadConfigSet(GPIO_PORTD_BASE, GPIO_PIN_7, GPIO_STRENGTH_8MA, GPIO_PIN_TYPE_STD_WPD);
    GPIODirModeSet(GPIO_PORTD_BASE, GPIO_PIN_7, GPIO_DIR_MODE_HW);

    Regards
    Amit
  • 0 in reply to Robert Adsett
    Expert 1875 points
    Hi Robert

    Thanks for your replied.

    I'm curious about the worse case or side effect when you enabled NMI on you case.

    Could you please share more information for me?

    thanks
    Gavin
  • 0 in reply to Gavin Lin1
    Guru 27665 points

    Certainly, although I may ramble a bit.

    Summary: In the worst case an NMI resembles a HCF (Halt and Catch Fire) instruction.

    Let's take a step back.  Consider what the basic characteristic of an interupt is.  An interrupt stops the current execution (on some processors this can be in the middle of an instruction) and switches to a new set of instructions. That is a rather severe action to take and it has consequences

    1. Care must be taken to preserve the current state (and restore it later)
    2. If an interrupt re-occurs while dealing with the first instance you can end up with the processor attempting to service the second event before it services the first.
    3. Any changes to memory made in the interrupt are made without the program being aware of them.  If the changes are to I/O locations then it can affect I/O.  The most common form of bug with this is a race condition and it can result in what appears to be nearly random behaviour.

    Now with standard interrupts all these consequences can be dealt with

    1. Standard entry and exit procedures are used to preserve and restore the current operating state and processor will often preserve at least a subset of the working registers.
    2. Most processors will automatically mask an interrupt against re-occurance whhile the first occurance is being serviced.
    3. Problems with multiple routines needing to change memory and I/O are dealt with by the main execution being able to prevent interrupts occuring that will affect operation while operating critical sections of the code. This can be something that disables all interrupts or a subset of the interrupts.

    The simple setup works well for most cases as long as the critical sections are kept short. Interrupts respond within the time of the longest critical section + the longest interrupt sequence tht can occur and the consequences of the interrupts can be managed. The problem occurs when you need a faster interrupt response than the longest critical time. Traditionally there have been two methods of dealing with this

    • Move processing out of the interrupts and into an RTOS/RTK. This can be used to shorten the critical sections and more importantly reduce the time spent in the interrupts in order to improve response time. The RTOS can also add a priority order to the interrupts and ensure higher frequency/importance event get dealt with first.
    • The other technique is to use a priority scheme for interrupts. So rather than an interrupt masking all other interrupts when it occurs it only prevents interrupts of the same or lesser priority from occurring.  This improves the response time of the high priority interrupts since they are only blocked during the longest critical section that affects them + the longest sequence of interrupts of equal or greater priority than them. The Cortex CPUs have this scheme built-in

    These techniques can be used together.

    Some people are tempted to use an NMI as the highest priority interrupt but consider what that means.

    Because the NMI is not maskable there is no way to create a critical section. There is really no recovery action you can safely take. You can safely read memory and I (as long as the inputs are not modified by the read).  You can safely write memory or output but only as long as no other interrupt or procedure in the code writes to that location or output.  And you can use single instruction non-interruptable  RMW sequences in both the main application and the NMI if you are careful. Anything else will create a race condition. The only other possible safe actions are to reset the processor or come to a complete halt.

    Even that subset is not necessarily safe.  Since the NMI is not maskable it can interrupt itself. There is a set of consequences from this

    • What ever action is done by the NMI may be repeated multiple times
    • The actions within the NMI may get their order shuffled
    • If there are enough re-occurances you will run out of stack and maybe other resources
    • The processor can spend extended amounts of time executing an NMI leaving no time for the application
    • The actual action the NMI is meant to perform may not be completed.

    It is only possible to prevent multiple reoccurences in hardware.  If the NMI is being used for something like a shutdown that can usually be done in H/W  as easily as preventing re-triggers of the interrupt allowing extra time to respond.

    The good news is that with the priority scheme and number of available interrupts there is very little reason (I think none) to use an NMI.

    And, yes, I have literally seen an NMI emulate an HCF instruction.

     

    Robert

  • 0 in reply to Robert Adsett
    Guru 47900 points
    Bravo!

    Simply terrific, Robert - thank you & very much appreciated...
  • 0 in reply to cb1
    TI__Guru**** 244400 points
    Hello Robert,

    Indeed. We should make this a featured post?

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

    Well - that's one possibility, Amit.  (but - rather outside Robert's main thrust - I believe)

    Why do two NMI (as default) pins exist?  Would not ONE cause sufficient "pain/suffering" to the 95%+ of users who have no knowledge of - nor need for - NMI?

    Robert argues against the need for any NMI - but those seeking that fine detail are few - and far between.  Surely the removal of those pins from, "Default to NMI" would meet Robert's - and so many other users' - approval...  And avoids the always problematic, "featured post!"  (how many find - read - comply with those?)

    Just as the (famed) 0-ohm Rs strike fear/disarray into new L-Pad users - should not the NMI pins be cast as normal GPIO - with the option to, "Order them into NMI - by those users -  skilled enough to require such?"  (ANS: mais certainement!)

    Same method would "fix" those 0-ohm Rs - compatibility is nice - but pack those Rs in a bag - to be installed (only) by those seeking such!  (a very clear minority - by any fair reading of user 0-ohm ills - long (& repeatedly) - reported here...)

    Of course - Robert & this reporter represent "NIH" - our ideas will never "see light of day" - and festering sores (invented HERE) will claim more victims...

  • 0 in reply to Robert Adsett
    Guru 86755 points
    Hi Robert,

    I saved a copy of your reply. Thanks.

    - kel
  • 0 in reply to Robert Adsett
    Expert 1875 points
    Hi Robert

    Thanks for your replied, that is the good lesson for me.

    And I think that NMI may be not the necessary implementation on my project.

    thanks
    Gavin
  • 0 in reply to Robert Adsett
    Guru 20670 points
    i have also saved your explanation. thank you very much
  • 0 in reply to Luis Afonso
    Guru 27665 points
    CB1, Amit, Kel, Luis and Gavin

    Thank you for your kind words

    Robert
  • 0 in reply to Amit Ashara
    Guru 27665 points

    Amit Ashara said:
     
    Indeed. We should make this a featured post?
     

     

    You may feel free to do so if you wish. 

    You may be in danger of running out of room for such items with the large font though ;)

     

    Robert

  • 0 in reply to cb1
    Guru 27665 points

    cb1- said:
    Robert argues against the need for any NMI

    Yep, although I think that ship has sailed for this processor.

    The presence on an NMI did give me a little pause when selecting the chip for use, but only a little. The ever-reoccuring configuration issues do argue against including it in future devices. 

    Robert

  • 0 in reply to Robert Adsett
    TI__Guru**** 244400 points
    Hello Robert,

    Not really. I would be consolidating a lot of the Sticky Posts and sending them over for Application Note or Integrating into existing Sticky Notes...

    Regards,
    Amit
  • 0 in reply to Amit Ashara
    Guru 47900 points

    Amit Ashara said:
    I would be consolidating a lot of the Sticky Posts and sending them over for Application Note or Integrating into existing Sticky Notes...

    But - as this poster has proved (and hundreds before him) - have not the "Sticky Notes" and (likely) unfound & unread App Notes - proved an abject failure?

    Believe that General Custer - returning to "Little Big Horn" - outnumbered & outmaneuvered by skilled foe - would meet same (overwhelming) defeat.

    And too - the "Band-Aid parade" of (too often ignored) sticky notes and (where are they now) App Notes - which may not precisely define their subject matter...

    Pretending such a fundamental flaw can be fixed by (yet more) of the same, failed, past techniques makes almost no sense!  (we seem NOT to learn/adapt!)

    As "proof" - look @ the subject of this thread - it's completely devoid of PF0/PD7 mention!  Would rushed/frustrated user "ever" think to read this - to escape his inability to bring PF0/PD7 to GPIO Life? 

    I'll bring the bass drum, Robert the bugle, Amit the stickies (and failed/hapless posters the tears!) - let the "Band-Aid Parade" begin...

  • 0 in reply to Amit Ashara
    Guru 27665 points
    Amit, An app note or some sort of tips page is a good idea.

    Robert
  • 0 in reply to cb1
    Guru 27665 points

    cb1, you are quite right that an app note won't prevent people from asking about PF0/PD7. What it does do is give a common place to point to. "Here go read this, come back if it leaves any questions". If such a note mentions multiple traps for the unwary it may prevent the need subsequent questions.

    I know, when I was starting, such notes saved me many an hour. Less so now when answers can be reached for with a few caresses of the keyboard. I'm afraid there are only a few of us left who actually read datasheets and user manuals fully. That's generally to our advantage I think, although even after reading it is quite possible to miss the significance of an offhand sentence.

    Robert

  • 0 in reply to Amit Ashara
    Prodigy 100 points
    Hello Amit,
    This information is very useful. Can you please tell me how to link the ISR for the NMI using API functions. I couldn't find any API function for that. Or otherwise as you have suggested, "the Interrupt Vector Map needs to be modified to have the function mapped in place of the default handler", how to map the ISR to the Vector table.

    Thanks a lot
    Dilgush
  • 0 in reply to Amit Ashara
    Prodigy 100 points
    Thanks Amit for the info.

    Can you please tell how to link the Default handler to this NMI ISR..
    Regards
    Dilgush.