• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 98 subscribers
  • Views 2750 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.

TI-RTOS interrupt question

Edward Averill
Genius 3100 points
Other Parts Discussed in Thread: MSP430F5638

I have a TI-RTOS based project, and I seek clarification on interrupt handling.

I have Hall sensor interrupts coming about once every 8-10 milliseconds.  They're coming in on Port1, pins 2-4.  When the edge of one of the Hall inputs transitions (low to high or high to low), I get an interrupt triggered so I can go out and commutate the BLDC motor.

What I'm seeing is dropped interrupts, where I expect the next state to ne X, but I see Y on the interrupt - as if the intermediate interrupt was dropped by the system.

This droppage seems to be entirely at random, I instrumented the living daylight out of the code and there's no pattern to the droppage whatsoever.

Based on my weak knowledge of the internals of TI-RTOS interrupt handling, an HWi will run to completion without interruption.  Therefore, for this to drop a Hall transition interrupt, something would have to stay in an interrupt routine fore more than 8-10 milliseconds!

We've put a scope on the board and can see that we're in and out of the Hall sensor ISR in about 4 milliseconds, so we know we're not stepping on our own feet.  'Our scope also confirms that the motor sensors aren't skipping a beat randomly, so our inputs look good.

\Is there anything going on in TI-RTOS that would potentially kill interrupts for a long time?  I am using USB to display debug output, could the USB processing somehow be kiboshing interrupts?  I'm using the USB CDC code from TI for my basic USB serial port emulation.

All help, suggestions, etc. appreciated!

Ed Averill

  • 0
    TI__Mastermind 26780 points

    Edward,

    Which device and which TI-RTOS version are you using?

    Note that the kernel interrupt latency – the max duration that interrupts are globally disabled by the SYS/BIOS kernel itself – is described in a benchmarking document included in the SYS/BIOS kernel product.  For example, open the TI-RTOS release notes in a browser, under “Products Included” click on the “bios_6_xx_yy_zz” link, then in those release notes click on “Benchmarks”, and then “Timing and Size Benchmarks”.  Look for your device target in the left column, and then click on the corresponding “times” link.  The first row on the page should show the corresponding Interrupt Latency number.

    That is for kernel latency.  I don’t know about possible USB interrupt latency.  If you tell me the device and TI-RTOS version I can ask around about what interrupt latency might be expected.

    Thanks,
    Scott

  • 0 in reply to ScottG
    Genius 3100 points

    Thanks for the reply!

    That benchmark document is very useful - I had no idea it even existed.

    T"I-RTOS version is 2.12.1.33, running on an MSP430F5638.  The clock is 16MHz., which I would expect is plenty fast for this application.

    Off to do more research...

    Ed Averill

  • 0 in reply to Edward Averill
    Genius 3100 points
    I see this in the TI RTOS manual:

    "All hardware interrupts run to completion. If a Hwi is posted multiple times before its ISR has a chance to
    run, the ISR runs only one time. For this reason, you should minimize the amount of code performed by
    a Hwi function.
    If interrupts are globally enabled—that is, by calling Hwi_enable()—an ISR can be preempted by any
    interrupt that has been enabled."

    ..this seems contradictory. Is this really saying that, if I manually re-enable interrupts, only then can my ISR be pre-empted?
  • 0 in reply to Edward Averill
    TI__Mastermind 26780 points

    Edward,

    Yes, if the MSP430 CPU is running in an ISR, by default no other ISRs can preempt it.  Until either 1) the ISR completes and does a return from interrupt, or until 2) global interrupts are re-enabled within the ISR, to allow nesting by other ISRs. 

    In the datasheet and elsewhere you’ll see mention of priority of hardware interrupts.  This priority only comes into play if there are two or more simultaneously pending hardware interrupts.  In this case, the highest priority of the pending interrupts will be serviced by the CPU first.

    There is some description of interrupt handling and nesting on this wiki page: http://processors.wiki.ti.com/index.php/SYS/BIOS_for_the_MSP430

    Scott

  • 0 in reply to ScottG
    Genius 3100 points

    That's a great Wiki page - I was really wondering about the operation of the guts of SYS/BIOS and I see a lot of places with opportunities for performance improvements.


    Thanks a ton!

    Ed Averill