• State TI Thinks Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 82 subscribers
  • Views 1165 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.

F28335 CPU Timer Priority

Richard Barnes1
Prodigy 20 points

Hi,

I need to achieve the following interupt priorities (highest to lowest):

TINT0 (CPU timer 0) - via PIE

TINT1 (CPU timer 1) - non-PIE

ECAN1INTA (CAN mailbox) - via PIE

Basically, I need two timers which cannot be interrupted by or stalled by CAN messages.

I have modified DSP2833x_SWPrioritizedIsrLevels.h to achieve this and notice that, although my CPU timer 1 does not get interrupted by CAN, it does appear to get stalled by the CAN interrupt. Is this because of the hardware priorities (INT9 being higher than INT13)? If so, what can be done to achieve the above requirement?

 

Any help is appreciated.

Regards

Richard

 

 

  • 0
    TI__Guru* 91940 points

    Richard Barnes1 said:
    CPU timer 1 does not get interrupted by CAN, it does appear to get stalled by the CAN interrupt. Is this because of the hardware priorities (INT9 being higher than INT13)? If so, what can be done to achieve the above requirement?

    Richard,

    If int9 is executing then it won't be interrupted by INT13 unless you have re-enabled interrupts within the ISR for int9.   When the CPU context switches to an ISR the INTM (interrupt mask) bit in the CPU status registers is automatically set holding off all additional interrupts.   This wiki article goes into more detail:

    http://processors.wiki.ti.com/index.php/Interrupt_Nesting_on_C28x

    Regards

    Lori

  • 0 in reply to Lori Heustess
    Prodigy 20 points

    Hi Lori and thanks for the reply.

    My ISR code does re-enable interrupts using the priority masks created within the DSP2833x_SWPrioritizedIsrLevels.h file; however I still notice that INT13 (T1) is stalled by INT9 (CAN). I read in the TI CPU literature that there is a hardware priority applied to INT1 to INT16 which I think may be causing this (INT1 being highest). Unless there is a way of changing this hardware priority, I cannot see how I can make INT13 interrupt INT9 as it is not part of the PIE.

    If this is the case, then my only option may be to create my second timer from an ADC sequencer interrupt as these are in PIE group 1 along with T0.

    Regards

    Richard

     

  • 0 in reply to Richard Barnes1
    TI__Guru* 91940 points

    Richard Barnes1 said:
    I read in the TI CPU literature that there is a hardware priority applied to INT1 to INT16 which I think may be causing this (INT1 being highest).

    Richard,

    Yes - the hardware priority determines which interrupt is serviced first, should two of them come in at the same time or if more than one are pending at the time interrupts are enabled..   When the CPU context switches the interrupt mask bit is set and all other interrupts are held off.  Once you are within an ISR you can allow a lower-priority interrupt to come in through software.  At this point the hardware priority doesn't hold off an interrupt (unless once again two interrupts are pending - again the highest will be taken first).

    -Lori