• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Subscribers 79 subscribers
  • Views 774 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.

MSP430F5328: Timer interrupt issue

Robert Buchanan
Intellectual 300 points
Part Number: MSP430F5328

Hello,

 

We are using an MSP430F5328 processor on one of out boards and are experiencing an interesting issue. The basic process is to use a PWM timer to periodically (every 2 mSecs) turn on an amplifier for a specific amount of time (200-300 uSecs).  Shortly after turning the amp on (90-150 uSecs) we generate an interrupt to process some data.  We are using TA0 for this.  The PWM output is on P1.4, so we are using TA0.3 for this.  And we are using TA0.2 to generate our interrupt.  The basic code is below:

              MOV.W         #TASSEL0+MC_1,&TA0CTL      ; set source to ACLK

                                                       ; mode to Up

                                                       ; divider = 1

                                                       ; don't enable interrupt yet

              MOV.W         #64,&TA0CCR0               ; set for 2mS timer (act = 1.95 mSec)

              MOV.W         #P1SAMPDELAY,&TA0CCR2      ; set delay timer for interrupt

              MOV.W         #OUTMOD_3,&TA0CCTL3; ; set for set/reset output mode

              MOV.W         #P1PWRDELAY,&TA0CCR3 ; set delay before POWER OFF

              BIS.B         #ORG_REG_EN,&P1SEL         ; set output pin to turn on PWM output (P1.4)

              BIS.W         #CCIE,&TA0CCTL2;           ; enable interrupt

 
 

  

This all works fine when using an IAR emulator. The timing is shown below:

 

 

The RED line is the amplifier output which starts at the start of the timer cycle. As can be seen, the power to the amp is cut off at 182 uSecs which is the designed time.  The BLUE line rises when the timer generates an interrupt at 93 uSecs, again the designed time.

 

However, when running the board without the emulator, whereas the PWM timing stays the same, the timing of the interrupt is extended significantly as can be seen in the screenshot below (this is with the same code and timing parameters as before, but here the interrupt doesn't occur until 228 uSecs as shown below:

 

If we change the delay for the interrupt to the minimum count, which should be about 30 uSecs, we get the timing shown below:

 

With this timer count, we get the interrupt 168 uSecs into the clock cycle rather than the 30 uSecs we would have expected.

 

What could possibly be causing this issue with the interrupt generation? Using timer TA0.1 rather than TA9.2 for this made no difference.

 

Any help would be appreciated.

 

Robert Buchanan

 

  • 0
    TI__Genius 12315 points

    Hi Robert,

    What's the actual frequency of ACLK and MCLK? And what's the value of P1SAMPDELAY and P1PWRDELAY?

    The MCU was running in debug mode or free mode?

  • 0 in reply to Winter Yu
    Intellectual 300 points

    Hi Winter,

    ACLK is 32768Hz external crystal, and MCLK is 3.5 MHz.  P1PWRDELAY is 6 for all 3 displays.  P1SAMPDELAY is 3 for the 1st two displays and 1 for the last display.  For the 1st display, the emulator was running in debug mode.

    Robert

  • 0 in reply to Robert Buchanan
    Guru 95585 points

    I'm supposing that the blue line is generated by software. My first guess is that something else is delaying the interrupt.

    Does every cycle look like this? If this is the first cycle, there might be e.g. powerup things keeping interrupts disabled. (The emulator keeps the chip powered constantly.)

  • 0 in reply to Bruce McKenney
    Intellectual 300 points

    Correct...the blue line is a test point output that gets set at the start of the interrupt routine.  It is very consistent.  The only other interrupt running is an interrupt used by our RF radio when it transmits data, which is about every 300 mS.  We did have a problem earlier with it keeping the interrupts disabled unnecessarily which was causing a delay once in a while even running with the interrupt.  But that was resolved some time ago and it usually only adversely affected the sample interrupt about once every 2 seconds. 

  • 0 in reply to Robert Buchanan
    Intellectual 300 points

    Some additional information on this issue...I tried running the processor at different speeds, up to 13.5 MHz and there was no difference in this interrupt latency (time differential between when I would expect the interrupt and when it actually occurs) when running stand-alone.  Also, I tried setting different timer settings for generating the interrupt.  In all cases, the latency was the same... ~135 uSecs.  Questions I have about this are:

    1.  Why don't I see this latency when running with the emulator?

    2.  Is there something in the processor that would cause this latency?

  • 0 in reply to Robert Buchanan
    Guru 95585 points

    Does every cycle look like this? Or only the first?

  • 0 in reply to Bruce McKenney
    Intellectual 300 points

    Every cycle looks like this...

  • 0 in reply to Robert Buchanan
    Guru 95585 points

    Are you using LPM3? If so you would be affected by t-wake-up-slow [Ref Data sheet (SLAS678D) p. 55 "Wake-up times"]

    The trick is that with the debugger attached you never actually get to LPM3, so this table doesn't apply. For non-debug, you would need to add something like:

                mov.b	#0a5h,&PMMCTL0_H		; Unlock
            bis.w	#SVMLFP+SVSLFP+SVSLMD,&SVSMLCTL		; Full Performance
            mov.b	#000h,&PMMCTL0_H		; Lock

  • 0 in reply to Bruce McKenney
    Intellectual 300 points

    Yes, I am using LPM3

    The interrupt latency was indeed what I was seeing.  Switching to full performance worked fine.

    Many thanks...

**Attention** This is a public forum