• State
  • Locked Locked
  • Replies 2 replies
  • Subscribers 78 subscribers
  • Views 429 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

MSP430F5638 Interrupt question

Edward Averill
Genius 3100 points

This is probably a no-brain question, but I'm seeing some oddness I'm not sure about.

The application is brushless DC motor control.  We have 3 Hall sensor inputs that let us determine things like the position of the shaft and the RPM.  Each of these lines is connected, via a buffer, to 3 GPIO pins on PORT1.  As a state changes, we flip the interrupt edge select so we catch HIGH-TO-LOW and LOW-TO-HIGH and can determine what to do based on these transitions.

I started seeing multiple, repeating interrupts when the state hasn't changed, and this puzzled me. I was assuming that, once I had processed a transition, toggled interrupt edge selection, and cleared the interrupt flag bits I'd not be bothered again until the next rising/falling edge on one of the monitored lines.. but this appears not to be true..

Breaking in the debugger in CCS 6 right before I clear the interrupt flags and single-stepping, I see some flags NOT being set to zero!  So, I do in and clear the flags by hand and  they  IMMEDIATELY come back!  Thus the interrupt re-triggers even though the input bit values haven't changed.

This seems downright wrong.  I changed te interrupt edge, I can see it in P1IES, but it's acting as if the interrupt state hasn't been cleared.

Is this "working as designed"?  Do I need to disable interrupts for any "stuck" lines and only enable interrupts for those I expect to transition?

All help appreciated, I'm running out of haair to tear out...

Ed Averill

  • 0
    Guru 23000 points

    I don’t know what and where the ‘edge’ changes are latched and if you can clear them, from your experience probably not.

    But the correct way to handle multiple Port.bit interrupts is to read the PxIV register and switch to, or save, the current served Port.bit interrupt (the bit with the highest priority), this will clear automatically the current served PxIFG.y and leaves all other unchanged.

    Check if your Hall sensors do not generate a bounced signal to the port-pin, electrically and/or mechanically.

    And keep the Port ISR –very- short.

  • 0 in reply to Leo Bosch
    Genius 3100 points

    Sorry about the delay - I was out sick yesterday and didn't have a chance to respond.

    I'll give your suggestions a try.  We've had a scope on the Hall inuts and they're clean coming in to the GPIO, there's a buffer chip between the raw sensor input and the GPIO so we're good to go there.

    I'm 100% certain it's something I'm doing wrong...

    Off to give the P1IV bit a shot!

    Ed Averill

**Attention** This is a public forum