• State
  • Locked Locked
  • Replies 10 replies
  • Subscribers 84 subscribers
  • Views 855 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.

280x ISR priority

SJU
Intellectual 665 points

Hi everyone,

I recently came across a problem where my highest priority ISR was not executing with the timing I expected.The only (quick) solution I found was to disable/hack off my other ISRs.

My assumption was that the priority of say SEQ1INT (ADC sequencer) being higher than a SPI or SCI interrupt, the CPU would make my SEQ1INT ISR take over even when a lower priority ISR was executing. My lower priority interrupts do not do anything like disabling INTM or playing with PIEIER during their execution. What I saw was that my SEQ1ISR would start executing after the lower priority ISR was finished, which was a bit of a problem for me.

Is there something I'm missing, or is this expected behavior ?

Thanks,

 

  • 0
    Genius 5885 points
    Hi SJU When you enter an ISR all the interrupts are disabled by the compiler via INTM bit. If you want to nest interrupts you should enable higher priority interrupts within low priority interrupts, (via masking the IER appropriately) and then enable interrupts. The assembly way of doing this is available in SPRAAN9 - example 24, while the C-way can be found in C/C++ Peripheral Header Files Examples Regards, Mitja
  • 0 in reply to Mitja Nemec
    Intellectual 665 points

    Oh, I see. I had missed the fact that the CPU sets INTM without software intervention when it services an interrupt. So clearing INTM upon entering a low priority ISR should solve my problem.

    Thanks a lot !

     

    Samuel

     

  • 0 in reply to Mitja Nemec
    Expert 1070 points

    This is a key note. I would suggest TI to better document the nested isr behavior. We were having a similar problem but would not find much hint from the documents (not to expect such important info being buried under FPU doc as an example... Thanks for the answer though.

  • 0 in reply to Leong
    TI__Guru* 93800 points

    Leong said:
    This is a key note. I would suggest TI to better document the nested isr behavior. We were having a similar problem but would not find much hint from the documents (not to expect such important info being buried under FPU doc as an example... Thanks for the answer though.

    Hi Leong,

    Thank you for the feedback on the documentation.  Did you by chance look at the interrupt chapter of the System Controls and Interrupts reference guide?   

    Cheers

    -Lori

  • 0 in reply to Lori Heustess
    Expert 1070 points

    Yes that's the document we went through. Through the whole document, there is no mentioning directly on "nested isr" topic never the less an example. "nested" actually never appears in this document.

     

    Thanks for the quick response.

  • 0 in reply to Leong
    TI__Guru* 93800 points

    Leong said:
    Yes that's the document we went through. Through the whole document, there is no mentioning directly on "nested isr" topic never the less an example. "nested" actually never appears in this document.

    Thank you for the details, Leong.   Looks like we need to add some additional information to section 6.3.1 that talks about the Procedure for software-prioritizing interrupts.  It isn't clear that the example mentioned is a method for nesting them.

    Cheers

    -Lori

  • 0 in reply to Lori Heustess
    Genius 5885 points

    Hi Lori,

     

    Speaking of feedback, it would be really nice if one would have the option to manually insert interrupt entry/exit code. Something in the way of __naked attribute that some compilers have or as it was the option with the C24xx compiler where one could change I&&SAVE and I$$RESTORE code.

    As it is now you have to code the interrupt function with assembly (if you want to have fast and flexible interrupt entry/exit code) and within that function you can call C function that does actual processing.

    Just a thought

     

    Regards, Mitja

  • 0
    Prodigy 90 points

    Just enable interrupt in the beginning of ISR.

     

    EI;

    or

    asm(" clrc INTM");

     

  • 0 in reply to Mitja Nemec
    TI__Guru* 93800 points

    Mitja Nemec said:

    Speaking of feedback, it would be really nice if one would have the option to manually insert interrupt entry/exit code. Something in the way of __naked attribute that some compilers have or as it was the option with the C24xx compiler where one could change I&&SAVE and I$RESTORE code.

    As it is now you have to code the interrupt function with assembly (if you want to have fast and flexible interrupt entry/exit code) and within that function you can call C function that does actual processing.

    Mitja,

    The compiler should already generate efficient entry/exit code.  Is your request so you can add additional functionality like enabling interrupts automatically to each ISR?

    -Lori

     

  • 0 in reply to Lori Heustess
    Genius 5885 points

    Lori,

    It is true that compiler generates efficient entry/exit code. I have just two remarks

    1. The code from example in above mentioned FPU primer has significantly less jitter when using nested interrupts, as interrupts are disabled for minimal required time. If one would write the same code in C, the compiler first performs required context save, than you can modify PIEIER and IER and only than can you enable interrupts.

    2. If one uses different RTOS than DSP/BIOS the the compiler generated interrupt entry/exit code, while efficient, only causes difficulties when porting. From my experience the code for the port can be either elegant (leaving compiler to do as much as it can) but inefficient or efficient (using assembly) but hard to maintain.

    Mitja