MSP430F5328: Timer interrupt issue

Robert Buchanan

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

over 6 years ago

0 Winter Yu over 6 years ago

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 Robert Buchanan over 6 years ago 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 Bruce McKenney over 6 years ago in reply to Robert Buchanan

Guru 101285 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 Robert Buchanan over 6 years ago 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 Robert Buchanan over 6 years ago 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 Bruce McKenney over 6 years ago in reply to Robert Buchanan

Guru 101285 points

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

0 Robert Buchanan over 6 years ago in reply to Bruce McKenney

Intellectual 300 points

Every cycle looks like this...

0 Bruce McKenney over 6 years ago in reply to Robert Buchanan

Guru 101285 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 Robert Buchanan over 6 years ago 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

MSP low-power microcontrollers

MSP low-power microcontroller forum

MSP430F5328: Timer interrupt issue