• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 83 subscribers
  • Views 636 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 can an interrupt handler get interrupted?

Christopher Taylor
Intellectual 690 points

I have configured 3 interrupts (HWI).  These are for a ADC conversion complete, CANBUS receive, and UART receive.  This is in a DSP Bios projects and the dispatcher is being used.  I have set no priorities for these interrupts.  I am toggling a GPIO pin  to test the timing of my ADCISR.  Inside this ISR there is a read of the ADC results.  According to my timing tests the majority of the time the read takes 1.068 us.  From time to time the read will take 13 us.  Other functions that I call from within the ISR are showing similar signs.  All seem to have a random instance of the function taking almost 12 us longer.  This leads me to believe that something is interrupting my interrupt.  Is this something with the DSP Bios dispatcher.  I need scheduling and synchronization but I also cannot have my motor control interrupt be interrupted.  I am using the F28335 chip and DSP Bios 5.41.10.36.

  • 0
    Intellectual 690 points

    Did some further checking and the dispatcher had been enabled in order to be able to post a semaphore.  I removed the semaphore and disabled the dispatcher.  At this point the ISR became stable again.  Therefore it was Bios that was interrupting my ISR.  This is unacceptable.

  • 0 in reply to Christopher Taylor
    Intellectual 280 points

    This is why I program bare silicon.  I need sub microsecond latencies, and ISRs that complete in 0.5 to 4 us.  DSP-BIOS doesn't interest me.

  • 0 in reply to Christopher Taylor
    TI__Guru* 93800 points

    Christopher Taylor said:

    Did some further checking and the dispatcher had been enabled in order to be able to post a semaphore.  I removed the semaphore and disabled the dispatcher.  At this point the ISR became stable again.  Therefore it was Bios that was interrupting my ISR.  This is unacceptable.

    Christopher,

    You may find this application note helpful  /informative.

    Using DSP/BIOS in C2800 Applications with High Interrupt Rates  www.ti.com/lit/spraax9

    Regards,

    Lori

     

  • 0 in reply to Lori Heustess
    Intellectual 280 points

    Thanks for the App Note tip.

    Table 4 in the document indicates that when using DSP/Bios the worst case latency is 88 cycles, and the lower bound is 16.  I think this is due to the fact that there are times when DSP-Bios has interrupts disabled. 

    If one is pushing the limits with ISRs that depend on 16 cycle latencies, then this potential occasional 88 cycle latency will break the application.

    It's good to have this documented.  It still seems to be that the only way to guarantee performance with applications that need consistently lower-bound interrupt latency is not to use DSP/Bios.  In my application with the potential for up to 576kHz interrupts interleaved with another source of up to 250kHz interrupts, DSP/Bios would break things.