• TI Thinks Resolved

MSP432E401Y: Interrupt Latency relative to FPU configuration

Expert 1030 points

Replies: 6

Views: 226

Part Number: MSP432E401Y

I'm trying to optimize and understand interrupt latency on the device and am trying to clear a few things up.  First, according to this:

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka16366.html

it seems that interrupt latency can be as low as 12 clock cycles (at least for a base reference design), plus another 17 possible with FPU.  As far as I can tell this is implementation dependent.

My measurements seem to indicate the 12+17 cycle latency for this device (~242ns with 120MHz clock).  I am using a PWM rising edge to GPIO toggle in the PWM interrupt to roughly measure this latency.

Additionally, the FPU function descriptions in driverlib seem to indicate that interrupt latency can vary using different settings (FPUStackingDisable, FPULazyStackingEnable, FPUStackingEnable, etc...).  I am changing these and noticing no difference, however.  Also, whenever I set FPUDisable(), I eventually hit a Hwi_excHandler, even though I also tell the compiler to stop using HW FPU instructions (--float_support=none).

My questions:

1) Is the 12+17 number expected for this device?
2) Why am I seeing no difference in interrupt latency when enabling or disabling FPU configurations that are documented as affecting it?
3) Would disabling the FPU entirely drop the 12+17 to just 12, or is that the absolute minimum available?
4) What is the proper procedure for disabling the FPU?  It seems the default is Enabled with FPUStacking disabled (at least in my TI RTOS based project)

Thanks!

  • Hello James,

    I do not have MSP432E401Y,  

    however, according to my understanding:

    ad 1) yes

    ad 2) if your interrupt does not use FPU you should see no difference

    ad 3) disabling FPU should drop x cycles by 17

    ad 4) For FPU disabling should be used:

    Regardiing TI-RTOS: 

    1) 12 cycles refers, marketing, to the simplest context switching, only Stack Pointer and Program Counter are preserved
    2) please, refer to "zero latency interrupts" to investigate your  issue further. 

    Best regards,
    Tom

    If I had answered to your question, please mark this post as Resolved.

  • In reply to Tomasz Kocon:

    Ahhh, I see.  I'll investigate the difference when using floats in an interrupt.  I'm already set up for "zero latency interrupts" on the one I'm testing with.

    Just a couple final confirmations:
    1) Is ~242ns the actual expected interrupt latency on this device with a 120MHz clock?
    2) Is the "minimizeLatency" configuration item under the Task rtos configuration going to have any effect while using zero latency interrupts?

    Thanks!

  • In reply to James McLaughlin:

    James,

    James McLaughlin
    I'll investigate the difference when using floats in an interrupt.


    Within an interrupt, process the minimum and post an swi call(), 

    ad 1) I do not have MSP432E401Y to test and confirm an interrupt latency @ 120 MHz.
    I do recommend a careful reading of a ref. manual. 
    Please remember that an interrupt response closing time would be affected by cache coherency and memory latency..

    ad 2) just a hint for TI-RTOS current and future optimizations, "zero latency interrupts" are out of TI-RTOS control.

    I am not an MCU programming professional.
    My statements are just for help and self learning.

    Best regards,
    Tom

    If I had answered to your question, please mark this post as Resolved.

  • In reply to Tomasz Kocon:

    Hello James,

    Are you looking for any further information on this topic? If not I would like to close this post.

    Thanks,
    Sai
  • In reply to Sai Reddy:

    Hi Sai,

    I'll have more questions after I have an opportunity to re-test it, but that won't be very soon.  Feel free to close it, thanks.

  • In reply to James McLaughlin:

    Hello James,

    Thanks for letting us know! Although I close this thread, you can still post here within the next 30 days to reopen, after which the thread will get locked. If you want to continue the discussion after the thread is locked, please use the "Ask a related question" button to start a new related thread.

    Thanks,
    Sai