• State Resolved
  • Locked Locked
  • Replies 12 replies
  • Subscribers 34 subscribers
  • Views 3451 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.

Enabling tail-chaining and late-arriving of interrupts in tm4c123gh6pm

Harshavardhan
Prodigy 30 points
Other Parts Discussed in Thread: TM4C123GH6PM

Hi Everyone,

I am developing a project using the tm4c123gh6pm (I am currently using the launchpad) and I am using two GPIO interrupts with different priorities. The project is extremely timing sensitive and I require the interrupts to be serviced as quickly as possible. Both the GPIO interrupts can be expected to be triggered simultaneously quite frequently, leading to preemption of the interrupt. I was reading about the tail-chaining and late-arriving features of the NVIC, and the datasheet mentions that the NVIC supports these features, under the heading Exception Handlers in Chapter 2. I wanted to know whether these features are already enabled, or whether the user should separately enable them if required. If the user must enable them, how should it be done?

Thank you for helping me. Please excuse me if this question has already been asked before in the forums and kindly direct me towards the answer.

Regards

Harsha 

  • 0
    Guru 117855 points

    May I commend you on a superbly thought, constructed & titled post?    Very well done!

    Believe vendor's most talented, "Amit" best serves your request.   (and one suspects he'll soon - be here)

    That said - we employ "just what you seek" but alas - from another vendor.    And - their write-up appears more detailed - and (may) overlap that here.   (or not)

    Should Amit (or others) not respond to your satisfaction please contact me via, "Conversation or Private Message." (found at your forum sign-up/registration page - near bottom)

  • 0 in reply to cb1_mobile
    Guru 11940 points

    Believe vendor's most talented, "Amit" best serves your request.

    Not sure if you need to wait. The NVIC is part of the core, and as such not vendor-specific. That means, all those features are "baked into the cake", i.e. they are properties of the core/NVIC, and you can't disable them. And second, those feature are the same across all Cortex M devices, no matter which vendor.

    For more formation, I suggest to look at the source - ARM:   http://infocenter.arm.com/

  • 0 in reply to f. m.
    Guru 47900 points

    f. m. said:
    The NVIC is part of the core, and as such not vendor-specific

    I'm not sure that statement rings - at all times - entirely true.   Much may be as you state - but I fear to make so blanket & general a categorization.

    As you & I are active @ "other ARM fora" - I've read that the "newer" M7 has "tweaked" certain aspects of the M7's NVIC - thus, "all Cortex M devices" may not entirely manage "all aspects" of the NVIC identically...

    In general I agree - but - as you/I surely know - "devil in the fine (and sometimes moving) details..."   (and - rumored - is an update to the link info you've noted...)

  • 0 in reply to cb1
    Guru 11940 points
    I'm not sure that statement rings - at all times - entirely true.


    Well, on the most detailed level, you are correct here. While the first few interrupt vectors are identical (about a dozen...), the rest of those vectors, and their total number, is vendor- and device-specific. I bravely skipped about those little details ...
    More important: because the NVIC is basically the same, most vendors don't bother to describe it within the documentation of their silicon. It would have been great if they at least pointed to ARMs Cortex M reference manuals. (Holds true for other core component, so this ARM manual is a "must read" for the serious developer.)
  • 0
    TI__Guru**** 244400 points
    Hello Harsha,

    As cb1 and f.m. mentioned there are "baked" along with the core. Hence they are enabled in the core. Makes it simpler to have them always instead of an enable/disable bit which would complicate exception handling.

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Guru 47900 points
    So - perhaps, "All's well which ends well." (one hopes)

    Two points remain - imho:

    a) an update to the ARM document is rumored - I'd watch for it

    b) while having something critical, "always there" may - in some cases - "ease" - many examples may be presented where, "Control rather than always there" may "better ease."

    Devil luxuriates in such detail - as always - end application - and resource readiness/availability - count so much....
  • 0 in reply to cb1
    Prodigy 30 points
    Thank you all for your responses and helping newcomers in the field.

    I have another doubt regarding handling of interrupts; I am executing several instructions inside the interrupt handlers which I have mentioned above (reading values from an ADC, writing and reading from GPIO pins, accessing the Flash memory ,etc.) However, I was told that executing many instructions inside interrupt handlers is not a good practice, and instead, it needs to be flagged and the required instructions need to be executed in the main code instead. I was wondering why this is required, and whether there is any possibility of the code failing due to this. I am aware of the behavior of the nested interrupts, and I am quite confident that they would not cause any problems during execution. Also, does the program become unpredictable if the size of the code exceeds some amount, and are there any restrictions on the size of the code?

    Thank you for reading through my question.

    Regards
    Harsha
  • 0 in reply to Harshavardhan
    Guru 11940 points

    I was wondering why this is required, and whether there is any possibility of the code failing due to this.

    That depends on one's interpretation of "code failing". Just think of it as the Nyquist criterion taken to the next level of abstraction. Your MCU might continue to run and not end up in a fault handler, but you application fails to achieve the designed purpose. In a worst-case scenario, it might end up spending 100% of it's time in one interrupt routine, leaving no cycles for other tasks and interrupts. Finally, it is a design issue if you process incoming data directly in the interrupt routine or elsewhere in your application - you must keep up with the data rate, else your application will not work correctly.

    That is one important task for an embedded developer - calculating the performance requirements of the application, and compare it to the actual performance the MCU core delivers.

    As a general advice, try to use as much hardware support as possible. If a peripheral offers DMA or a FIFO, use it to relief the core from interrupt burden, and process incoming data as larger blocks. For "n" data items, you are saving "(n-1) * 2 * 12" core cycles otherwise spent within interrupts.

  • 0 in reply to Harshavardhan
    Guru 27665 points

    This is worthy of a rather length discussion of the reasons behind that recommendation.  It is, in fact, sometimes preferred to do everything in the interrupt. By far the more usual case is not to do very much in the interrupt.

    In fact in an RTOS/RTK environment there are often three levels of response to an interrupt

    1. The interrupt itself which does the minimum required to service the hardware and remove any data that could be lost by subsequent interrupts. The interrupt then passes along any data and flags the interrupt task.
    2. The interrupt task is the lowest level of the tasking environment, it does have a priority assigned and unlike the interrupt it has access to (a possibly limited subset) of the RTOS/RTK synchronization primitives.  It most of any remaining hardware interaction and queues data to tasks that are fully RTOS capable.
    3. Finally the RTOS task does the heavy lifting.  It has full access to all the synchronization and priority mechanisms.

    The reason for the interrupt task to exist is to remove the overhead of the RTOS from the interrupt. The interface between the interrupt and the Interrupt Task is lightweight not adding much time to the interrupt response. Simpler systems do not use the interrupt task concept.

    What happens if you do everything in the interrupt?

    • Latency increases. As long as the interrupt is being processed it hold off other interrupts at the same or lesser priority. So these interrupts take longer to respond and may lose vital information.  Note that this includes the interrupt that is running.
    • This lengthy interrupt process limits the rate at which you can accept interrupts.  Obviously if your average processing time exceeds the time available between interrupts you have a problem, but by limiting the time in the interrupt you allow higher short term rates of interrupt.
    • Program structure often suffers.  Many operations rely on information from several sources.  If you attempt to do this all at interrupt time synchronization quickly becomes an issue.
    • Waiting in an interrupt is very bad. It magnifies the earlier problems stated.  This means you lose access to most inter process communication primitives, print functions, pauses etc..
    • I'm sure you can work out more....

    Robert

    Edit: Spelling correction Not --> Note in first point of second section

  • 0 in reply to Harshavardhan
    Guru 47900 points

    Harshavardhan said:
    aware of the behavior of the nested interrupts, and I am quite confident that they would not cause any problems during execution.

    First - the posts of f.m. & Robert - in combination - imho qualify as, "Outstanding!"    (so good that I've copy/pasted into our firm's, "required MCU reading" file)   Posts here tend to rotate (too soon) away from quick/easy view - copy/paste much extends their value & impact!

    That said - I'm concerned with your, "expression of confidence" - especially so as it has not been supported with (any) related fact & findings.    Those vital details usually - but not always - are required for such confidence to not have been, "misplaced."  

    It is rarely wise to place confidence in hopes, assumptions, quick "in the head" calculations.    Careful measurement & charting of those relevant code functions - under all possible conditions (even those considered "remote") provides a far superior method to insure that your program, "Meets its stated objectives."   Only "then" would confidence (perhaps) be justified.    (yet I'd still be "on guard")

  • 0 in reply to cb1
    Guru 27665 points

    cb1- said:
      (so good that I've copy/pasted into our firm's, "required MCU

    Thank you sir.

    cb1- said:
    Only "then" would confidence (perhaps) be justified.    (yet I'd still be "on guard")

    Indeed, little surprises so completely as discovering what we know to be true isn't. We will search for all kinds of unlikely explanations before re-examining our previous knowledge.

    Robert

  • 0 in reply to Robert Adsett
    Guru 117855 points

    Robert Adsett said:
    ...little surprises so completely as discovering what we know to be true isn't.

    And this quote has been "cut/pasted" into our firm's, "Instructive & Memorable phrases" file.

    Brings to mind an ex US Def. Secretary who often spoke of, "Known unknowns" and (drumbeat) "Unknown unknowns!"   

    When our confidence "springs" from things we've not yet discovered - or absorbed - how "valid" might it be?