This is actually well thought out in my opinion. A reasonable trade off
between hundreds of ISR vectors for each peripheral, and optimised
processing time. If you need absolutely ever clock cycle for the ISR use
TimrA_0, if not use one of the others, where you add time for processing
TAIV and TAIFG. A good compromise, but then what do I know.
Al
michelqv wrote:
>Yeah, TI is so cheap that they did not add a second
CPU to monitor
>the first one and check that every step it takes is not
"spurious".
>I'm sure that if the flag was not automatically reset upon entering
>the ISR, some people (who shall remain nameless) would complain that
>they have to waste an instruction to clear the flag in the ISR.
>
>Michel
>
>--- In msp430@msp4..., <alex@s...> wrote:
>
>
>>Good to hear about you again Augusto. Hope your travels are all
>>
>>
>for pleasure
>
>
>>:)
>>The UM specifies the TAIFG as a "pending interrupt" flag. This
>>
>>
>implies, at
>
>
>>least to me
>>that once in the ISR you can check this flag to validate the
>>
>>
>interrupt. In
>
>
>>turn
>>this means that the flag should remain set until the first
>>
>>
>register read.
>
>
>>This is not what I see in my program.
>>I can see that TAR is equal to CCR0 and I infer that this is why
>>
>>
>the program
>
>
>>vectored
>>but I would like to have a confirmation. If TAIFG and TAIV are not
>>
>>
>visible
>
>
>>during ISR,
>>how do I know that I have not vectored because of a spurious IRQ?
>>
>>Alex
>>
>>
>>----- Original Message -----
>>From: "aee" <aee@t...>
>>To: "msp430" <msp430@msp4...>
>>Sent: Thursday, September 08, 2005 1:12 PM
>>Subject: Re:Fw: [msp430] TAIFG Take 2.
>>
>>
>>Alex,
>>Can't remember it now (and I'm traveling with no access to
user
>>
>>
>guide) but I
>
>
>>belive TAIFG is resetd by hardware when the interrupt is serviced.
>>
>>
>So, you
>
>
>>should read it as zero.
>>The way to check would be to disable global interrupts and check
>>
>>
>TAIFG by
>
>
>>polling.
>>-Augusto
>>
>>De:msp430@msp4...
>>
>>Para:msp430@msp4...
>>
>>Cia:
>>
>>Data:Thu, 8 Sep 2005 12:44:55 -0400
>>
>>Assunto:Fw: [msp430] TAIFG Take 2.
>>
>>
>>
>>>To plagiate a member of this List :)
>>>
>>>Anyone? This is NOT an IAR question :)
>>>
>>>Alex
>>>
>>>
>>>
>>>----- Original Message -----
>>>From:
>>>To:
>>>Sent: Wednesday, September 07, 2005 7:48 PM
>>>Subject: [msp430] TAIFG
>>>
>>>
>>>
>>>
>>>>Not sure why this happens, but when my TimerA ISR is vectored
>>>>
>>>>
>to, I can
>
>
>>>see
>>>
>>>
>>>>that the TAIFG is clear.
>>>>TAIV = 0;
>>>>TACTL = 0101H
>>>>TACCTL0, TACCTL1, TACCTL2 = 0010H
>>>>TAR = 7FFEH
>>>>TACCR0 = 7FFEH
>>>>TACCR1, TACCR2 = 0
>>>>
>>>>The timer is in mode 1 (MC_1).
>>>>
>>>>can any one explain why TAIFG is clear when entering the ISR ?
>>>>TIA,
>>>>
>>>>Alex
>>>>
>>>>
>>>>
>>>>
>>>>.
>>>>
>>>>
>>>>Yahoo! Groups Links
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>---
>>>>avast! Antivirus: Inbound message clean.
>>>>Virus Database (VPS): 0536-0, 09/05/2005
>>>>Tested on: 9/7/2005 7:49:40 PM
>>>>avast! - copyright (c) 1988-2005 ALWIL Software.
>>>>http://www.avast.com
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>.
>>>
>>>
>>>Yahoo! Groups Links
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>>
>>.
>>
>>
>>Yahoo! Groups Links
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>---
>>avast! Antivirus: Inbound message clean.
>>Virus Database (VPS): 0536-0, 09/05/2005
>>Tested on: 9/8/2005 1:16:51 PM
>>avast! - copyright (c) 1988-2005 ALWIL Software.
>>http://www.avast.com
>>
>>
>
>
>
>
>
>.
>
>
>Yahoo! Groups Links
>
>
>
>
>
>
>
>
>
>
TAIFG
Started by ●September 7, 2005
Reply by ●September 8, 20052005-09-08
Reply by ●September 8, 20052005-09-08
There is another factor, too, isn't there? Let's say you have a rapidly-occurring event. There may be latency before you service the event. "Use it or lose it"--if a second event occurs before the flag is cleared... If the event flag is cleared when the servicing routine is entered, then the next event can occur during the servicing of the prior and not be lost. Lee --- In msp430@msp4..., Onestone <onestone@b...> wrote: > This is actually well thought out in my opinion. A reasonable trade off > between hundreds of ISR vectors for each peripheral, and optimised > processing time. If you need absolutely ever clock cycle for the ISR use > TimrA_0, if not use one of the others, where you add time for processing > TAIV and TAIFG. A good compromise, but then what do I know. > > Al > > michelqv wrote: > > >Yeah, TI is so cheap that they did not add a second CPU to monitor > >the first one and check that every step it takes is not "spurious". > >I'm sure that if the flag was not automatically reset upon entering > >the ISR, some people (who shall remain nameless) would complain that > >they have to waste an instruction to clear the flag in the ISR. > > > >Michel > > > >--- In msp430@msp4..., <alex@s...> wrote: > > > > > >>Good to hear about you again Augusto. Hope your travels are all > >> > >> > >for pleasure > > > > > >>:) > >>The UM specifies the TAIFG as a "pending interrupt" flag. This > >> > >> > >implies, at > > > > > >>least to me > >>that once in the ISR you can check this flag to validate the > >> > >> > >interrupt. In > > > > > >>turn > >>this means that the flag should remain set until the first > >> > >> > >register read. > > > > > >>This is not what I see in my program. > >>I can see that TAR is equal to CCR0 and I infer that this is why > >> > >> > >the program > > > > > >>vectored > >>but I would like to have a confirmation. If TAIFG and TAIV are not > >> > >> > >visible > > > > > >>during ISR, > >>how do I know that I have not vectored because of a spurious IRQ? > >> > >>Alex > >> > >> > >>----- Original Message ----- > >>From: "aee" <aee@t...> > >>To: "msp430" <msp430@msp4...> > >>Sent: Thursday, September 08, 2005 1:12 PM > >>Subject: Re:Fw: [msp430] TAIFG Take 2. > >> > >> > >>Alex, > >>Can't remember it now (and I'm traveling with no access to user > >> > >> > >guide) but I > > > > > >>belive TAIFG is resetd by hardware when the interrupt is serviced. > >> > >> > >So, you > > > > > >>should read it as zero. > >>The way to check would be to disable global interrupts and check > >> > >> > >TAIFG by > > > > > >>polling. > >>-Augusto > >> > >>De:msp430@msp4... > >> > >>Para:msp430@msp4... > >> > >>Cia: > >> > >>Data:Thu, 8 Sep 2005 12:44:55 -0400 > >> > >>Assunto:Fw: [msp430] TAIFG Take 2. > >> > >> > >> > >>>To plagiate a member of this List :) > >>> > >>>Anyone? This is NOT an IAR question :) > >>> > >>>Alex > >>> > >>> > >>> > >>>----- Original Message ----- > >>>From: > >>>To: > >>>Sent: Wednesday, September 07, 2005 7:48 PM > >>>Subject: [msp430] TAIFG > >>> > >>> > >>> > >>> > >>>>Not sure why this happens, but when my TimerA ISR is vectored > >>>> > >>>> > >to, I can > > > > > >>>see > >>> > >>> > >>>>that the TAIFG is clear. > >>>>TAIV = 0; > >>>>TACTL = 0101H > >>>>TACCTL0, TACCTL1, TACCTL2 = 0010H > >>>>TAR = 7FFEH > >>>>TACCR0 = 7FFEH > >>>>TACCR1, TACCR2 = 0 > >>>> > >>>>The timer is in mode 1 (MC_1). > >>>> > >>>>can any one explain why TAIFG is clear when entering the ISR ? > >>>>TIA, > >>>> > >>>>Alex > >>>> > >>>> > >>>> > >>>> > >>>>. > >>>> > >>>> > >>>>Yahoo! Groups Links > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>--- > >>>>avast! Antivirus: Inbound message clean. > >>>>Virus Database (VPS): 0536-0, 09/05/2005 > >>>>Tested on: 9/7/2005 7:49:40 PM > >>>>avast! - copyright (c) 1988-2005 ALWIL Software. > >>>>http://www.avast.com > >>>> > >>>> > >>>> > >>>> > >>>> > >>> > >>> > >>>. > >>> > >>> > >>>Yahoo! Groups Links > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >> > >> > >> > >> > >> > >>. > >> > >> > >>Yahoo! Groups Links > >> > >> > >> > >> > >> > >> > >> > >> > >> > >>--- > >>avast! Antivirus: Inbound message clean. > >>Virus Database (VPS): 0536-0, 09/05/2005 > >>Tested on: 9/8/2005 1:16:51 PM > >>avast! - copyright (c) 1988-2005 ALWIL Software. > >>http://www.avast.com > >> > >> > > > > > > > > > > > >. > > > > > >Yahoo! Groups Links > > > > > > > > > > > > > > > > > > > >
Reply by ●September 8, 20052005-09-08
You're right, but this is all a part of the rapid ISR service. With
ISR's that don't clear the flag in hardware I always clear the flag as
the first instruction, except if for some very obscure reason I may not
want to queue the next interrupt until certain steps have been taken.
Cheers
Al
budfrog99 wrote:
>There is another factor, too, isn't there?
Let's say you have a
>rapidly-occurring event. There may be latency before you service the
>event. "Use it or lose it"--if a second event occurs before the
flag
>is cleared...
>
>If the event flag is cleared when the servicing routine is entered,
>then the next event can occur during the servicing of the prior and
>not be lost.
>
>Lee
>
>--- In msp430@msp4..., Onestone <onestone@b...> wrote:
>
>
>>This is actually well thought out in my opinion. A reasonable trade
>>
>>
>off
>
>
>>between hundreds of ISR vectors for each peripheral, and optimised
>>processing time. If you need absolutely ever clock cycle for the
>>
>>
>ISR use
>
>
>>TimrA_0, if not use one of the others, where you add time for
>>
>>
>processing
>
>
>>TAIV and TAIFG. A good compromise, but then what do I know.
>>
>>Al
>>
>>michelqv wrote:
>>
>>
>>
>>>Yeah, TI is so cheap that they did not add a second CPU to monitor
>>>the first one and check that every step it takes is not
"spurious".
>>>I'm sure that if the flag was not automatically reset upon
>>>
>>>
>entering
>
>
>>>the ISR, some people (who shall remain nameless) would complain
>>>
>>>
>that
>
>
>>>they have to waste an instruction to clear the flag in the ISR.
>>>
>>>Michel
>>>
>>>--- In msp430@msp4..., <alex@s...> wrote:
>>>
>>>
>>>
>>>
>>>>Good to hear about you again Augusto. Hope your travels are all
>>>>
>>>>
>>>>
>>>>
>>>for pleasure
>>>
>>>
>>>
>>>
>>>>:)
>>>>The UM specifies the TAIFG as a "pending interrupt"
flag. This
>>>>
>>>>
>>>>
>>>>
>>>implies, at
>>>
>>>
>>>
>>>
>>>>least to me
>>>>that once in the ISR you can check this flag to validate the
>>>>
>>>>
>>>>
>>>>
>>>interrupt. In
>>>
>>>
>>>
>>>
>>>>turn
>>>>this means that the flag should remain set until the first
>>>>
>>>>
>>>>
>>>>
>>>register read.
>>>
>>>
>>>
>>>
>>>>This is not what I see in my program.
>>>>I can see that TAR is equal to CCR0 and I infer that this is why
>>>>
>>>>
>>>>
>>>>
>>>the program
>>>
>>>
>>>
>>>
>>>>vectored
>>>>but I would like to have a confirmation. If TAIFG and TAIV are
>>>>
>>>>
>not
>
>
>>>>
>>>>
>>>>
>>>>
>>>visible
>>>
>>>
>>>
>>>
>>>>during ISR,
>>>>how do I know that I have not vectored because of a spurious
IRQ?
>>>>
>>>>Alex
>>>>
>>>>
>>>>----- Original Message -----
>>>>From: "aee" <aee@t...>
>>>>To: "msp430" <msp430@msp4...>
>>>>Sent: Thursday, September 08, 2005 1:12 PM
>>>>Subject: Re:Fw: [msp430] TAIFG Take 2.
>>>>
>>>>
>>>>Alex,
>>>>Can't remember it now (and I'm traveling with no
access to user
>>>>
>>>>
>>>>
>>>>
>>>guide) but I
>>>
>>>
>>>
>>>
>>>>belive TAIFG is resetd by hardware when the interrupt is
>>>>
>>>>
>serviced.
>
>
>>>>
>>>>
>>>>
>>>>
>>>So, you
>>>
>>>
>>>
>>>
>>>>should read it as zero.
>>>>The way to check would be to disable global interrupts and check
>>>>
>>>>
>>>>
>>>>
>>>TAIFG by
>>>
>>>
>>>
>>>
>>>>polling.
>>>>-Augusto
>>>>
>>>>De:msp430@msp4...
>>>>
>>>>Para:msp430@msp4...
>>>>
>>>>Cia:
>>>>
>>>>Data:Thu, 8 Sep 2005 12:44:55 -0400
>>>>
>>>>Assunto:Fw: [msp430] TAIFG Take 2.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>To plagiate a member of this List :)
>>>>>
>>>>>Anyone? This is NOT an IAR question :)
>>>>>
>>>>>Alex
>>>>>
>>>>>
>>>>>
>>>>>----- Original Message -----
>>>>>From:
>>>>>To:
>>>>>Sent: Wednesday, September 07, 2005 7:48 PM
>>>>>Subject: [msp430] TAIFG
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>Not sure why this happens, but when my TimerA ISR is
vectored
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>to, I can
>>>
>>>
>>>
>>>
>>>>>see
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>that the TAIFG is clear.
>>>>>>TAIV = 0;
>>>>>>TACTL = 0101H
>>>>>>TACCTL0, TACCTL1, TACCTL2 = 0010H
>>>>>>TAR = 7FFEH
>>>>>>TACCR0 = 7FFEH
>>>>>>TACCR1, TACCR2 = 0
>>>>>>
>>>>>>The timer is in mode 1 (MC_1).
>>>>>>
>>>>>>can any one explain why TAIFG is clear when entering the
ISR ?
>>>>>>TIA,
>>>>>>
>>>>>>Alex
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>.
>>>>>>
>>>>>>
>>>>>>Yahoo! Groups Links
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>---
>>>>>>avast! Antivirus: Inbound message clean.
>>>>>>Virus Database (VPS): 0536-0, 09/05/2005
>>>>>>Tested on: 9/7/2005 7:49:40 PM
>>>>>>avast! - copyright (c) 1988-2005 ALWIL Software.
>>>>>>http://www.avast.com
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>.
>>>>>
>>>>>
>>>>>Yahoo! Groups Links
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>.
>>>>
>>>>
>>>>Yahoo! Groups Links
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>---
>>>>avast! Antivirus: Inbound message clean.
>>>>Virus Database (VPS): 0536-0, 09/05/2005
>>>>Tested on: 9/8/2005 1:16:51 PM
>>>>avast! - copyright (c) 1988-2005 ALWIL Software.
>>>>http://www.avast.com
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>.
>>>
>>>
>>>Yahoo! Groups Links
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>
>
>
>
>
>.
>
>
>Yahoo! Groups Links
>
>
>
>
>
>
>
>
>
>
Reply by ●September 9, 20052005-09-09
Greg you need to read the whole user guide, Timerx_0 is handled
differently to the other timers, it does not route through the TAIV
mechanism.
Greg Maki wrote:
>alex@alex... wrote:
>
>
>>Greg,
>>First instruction in the ISR is:
>>i++;
>>
>>Just a dummy instruction where I set the break point. Once the
breakpoint is
>>stopping the
>>program, the C-SPY is showing the Timer A registers as they have been
>>captured at
>>the time of the Break Point. There was no read or write by my program on
any
>>of the TimerA registers. This is where I see that TAIFG is clear.
>>Is this normal ?
>>Alex
>>
>>
>>
>
>Alex,
>
>I just tried it and it does look like the flag is cleared when entering
>the interrupt, before TAIV is accessed. It does seem to contradict what
>the user manual states.
>
>Greg
>
>
>
>.
>
>
>Yahoo! Groups Links
>
>
>
>
>
>
>
>
>
>
>
Reply by ●September 9, 20052005-09-09
For anyone still struggling with this, RTFM Familuy User Guide for the
1xx family, but it doesn't matter TimerA works the sme on all members.
11-17 TACCR0 INTERRUPT
"The TACCR0 CCIFG flag has the highest Timer_A interrupt priority and
hasa dedicated interrupt vector as shown in Figure 11-15. The TACCR0
CCIFG flag is automatically reset when the TACCR0 interrupt request is
serviced"
There is no anomaly, no fault, no failure no unusual condition. It is
well deocumented.
Cheers
Al
alex@alex... wrote:
>hmmmm....I need to experiment a bit more ...
>But it is good to have an external confirmation that I do not dream :)
>Thanks, Greg
>
>Alex
>
>
>----- Original Message -----
>From: "Greg Maki" <gmaki@gmak...>
>To: <msp430@msp4...>
>Sent: Thursday, September 08, 2005 3:34 PM
>Subject: Re: Fw: [msp430] TAIFG Take 2.
>
>
>
>
>>alex@alex... wrote:
>>
>>
>>>Greg,
>>>First instruction in the ISR is:
>>>i++;
>>>
>>>Just a dummy instruction where I set the break point. Once the
>>>
>>>
>breakpoint is
>
>
>>>stopping the
>>>program, the C-SPY is showing the Timer A registers as they have
been
>>>captured at
>>>the time of the Break Point. There was no read or write by my
program on
>>>
>>>
>any
>
>
>>>of the TimerA registers. This is where I see that TAIFG is clear.
>>>Is this normal ?
>>>Alex
>>>
>>>
>>>
>>Alex,
>>
>>I just tried it and it does look like the flag is cleared when entering
>>the interrupt, before TAIV is accessed. It does seem to contradict what
>>the user manual states.
>>
>>Greg
>>
>>
>>
>>.
>>
>>
>>Yahoo! Groups Links
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>---
>>avast! Antivirus: Inbound message clean.
>>Virus Database (VPS): 0536-0, 09/05/2005
>>Tested on: 9/8/2005 4:10:56 PM
>>avast! - copyright (c) 1988-2005 ALWIL Software.
>>http://www.avast.com
>>
>>
>>
>>
>>
>
>
>
>
>.
>
>
>Yahoo! Groups Links
>
>
>
>
>
>
>
>
>
>
>
Reply by ●September 9, 20052005-09-09
Onestone wrote: > Greg you need to read the whole user guide, Timerx_0 is handled > differently to the other timers, it does not route through the TAIV > mechanism. Hi Al, My understanding is that there are two interrupt vectors for TimerA. One for CCR0, which does clear the flag when the interrupt vector is taken, and one for CCR1, CCR2 and TAIFG which has the highest-priority flag cleared when TAIV is accessed. I'm sure you're right about this. I would just like to see where I missed it in the manual. Best regards, Greg > > Greg Maki wrote: > > >alex@alex... wrote: > > > > > >>Greg, > >>First instruction in the ISR is: > >>i++; > >> > >>Just a dummy instruction where I set the break point. Once the > breakpoint is > >>stopping the > >>program, the C-SPY is showing the Timer A registers as they have been > >>captured at > >>the time of the Break Point. There was no read or write by my program > on any > >>of the TimerA registers. This is where I see that TAIFG is clear. > >>Is this normal ? > >>Alex > >> > >> > >> > > > >Alex, > > > >I just tried it and it does look like the flag is cleared when entering > >the interrupt, before TAIV is accessed. It does seem to contradict what > >the user manual states. > > > >Greg > > > > > > > >. > > > > > >>. > > > > -- =========================================================Greg Maki PHONE: 239-772-9067 Technocean, Inc. FAX: 815-572-8279 820 N.E. 24th Lane email to: gmaki@gmak... Unit 112 http://www.technocean.com Cape Coral, FL 33909 ==========================================================
Reply by ●September 9, 20052005-09-09
Hi Greg, see my later reply to Alex. In his original post Alex was
specifically using Timer_A0, hence my response. It's 11-17 in the FUG.
Cheers
Al
Greg Maki wrote:
>Onestone wrote:
>
>
>>Greg you need to read the whole user guide, Timerx_0 is handled
>>differently to the other timers, it does not route through the TAIV
>>mechanism.
>>
>>
>
>Hi Al,
>
>My understanding is that there are two interrupt vectors for TimerA. One
>for CCR0, which does clear the flag when the interrupt vector is taken,
>and one for CCR1, CCR2 and TAIFG which has the highest-priority flag
>cleared when TAIV is accessed.
>
>I'm sure you're right about this. I would just like to see where I
>missed it in the manual.
>
>Best regards,
>
>Greg
>
>
>
>>Greg Maki wrote:
>>
>> >alex@alex... wrote:
>> >
>> >
>> >>Greg,
>> >>First instruction in the ISR is:
>> >>i++;
>> >>
>> >>Just a dummy instruction where I set the break point. Once the
>>breakpoint is
>> >>stopping the
>> >>program, the C-SPY is showing the Timer A registers as they
have been
>> >>captured at
>> >>the time of the Break Point. There was no read or write by my
program
>>on any
>> >>of the TimerA registers. This is where I see that TAIFG is
clear.
>> >>Is this normal ?
>> >>Alex
>> >>
>> >>
>> >>
>> >
>> >Alex,
>> >
>> >I just tried it and it does look like the flag is cleared when
entering
>> >the interrupt, before TAIV is accessed. It does seem to contradict
what
>> >the user manual states.
>> >
>> >Greg
>> >
>> >
>> >
>> >.
>> >
>> >
>> >>.
>>
>>
>>
>>
>>
>>
>
>
>
Reply by ●September 9, 20052005-09-09
Onestone wrote:
> Hi Greg, see my later reply to Alex. In his
original post Alex was
> specifically using Timer_A0, hence my response. It's 11-17 in the FUG.
>
> Cheers
>
> Al
>
Hey Al,
I just looked over his original post and see that his code shows that he
set CCR0 to 0x7FFE so he is using Timer_A0. I assumed since he was
checking the TAIFG he was using the Timer_A1 interrupt. Looks like he is
taking the Timer_A0 vector but checking the TAIFG which, of course, will
never be set since he is in UP mode.
Cheers!
Greg
Reply by ●September 9, 20052005-09-09
The following program has been used to verify the Timer A TAIFG operation.
It is a modified version of
a TI supplied sample code.
The Results indicate a problem with either the USB FET or the IAR Interface.
A scope has been attached to P1.01 to observe the output waveform.
There have been run two tests, one under the IAR program control, the other
with
the FET disconnected and power applied from 2 "D" batteries.
With the FET connected and with IAR in debug "GO" mode the resulting
waveform was extremely
jittery, while when the run with the FET disconnected showed a clean and
stable waveform.
This indicates that while the program is run under the IAR Debug control
some
Interrupts were missed.
A run to breakpoint set to the first instruction in the ISR showed always
that the first time thru it,
the TAIFG is never set while the TAR was equal to CCR0!
The "temp" counter is breakpoint and it will stop the run every 2, 5
minutes.
In conclusion, TI Docs are right ! TAIFG is a STICKY flag that needs to be
reset at the end of the ISR.
A small note. when Timer A is used in this mode (Continuous UP) load not
only CCR0 but also CCR1 @ CCR2
with some dummy values. Otherwise the corresponding CCIFG will also be set
because the CCRn are reset to
zero at reset (TAR becomes zero after counting to CCR0)
Conclusion. Do not trust the USBFET combination and IAR. Between these two,
I lost about 2 days tracking down this problem.
Alex
===========================================================================//**************************************************************************
****
// MSP-FET430P140 Demo - Timer_A, Toggle P1.0, CCR0 Up Mode ISR, 32kHz ACLK
//
// Description: Toggle P1.0 using software and the TA_0 ISR. Timer_A is
// configured for up mode, thus the timer overflows when TAR counts
// to CCR0. In this example, CCR0 is loaded with 1000-1.
// Toggle rate = 32768/(2*1000) = 16.384
// ACLK = TACLK = 32768Hz, MCLK = SMCLK = default DCO ~800kHz
// //* An external watch crystal on XIN XOUT is required for ACLK *//
//
// MSP430F149
// ---------------
// /|\| XIN|-
// | | | 32kHz
// --|RST XOUT|-
// | |
// | P1.0|-->LED
//
// M. Buccini
// Texas Instruments Inc.
// Feb 2005
// Built with IAR Embedded Workbench Version: 3.21A
//**************************************************************************
****
#include <msp430x16x.h>
int temp;
void main(void)
{
temp=0;
WDTCTL = WDTPW + WDTHOLD; // Stop WDT
P1DIR |= 0x01; // P1.0 output
CCTL0 = CCIE; // CCR0 interrupt enabled
CCR0 = 0x7fff;
CCR1 = 0x9000;
CCR2 = 0xa000;
TACTL = TASSEL_1 + MC_1; // ACLK, upmode
//_BIS_SR(LPM3_bits + GIE); // Enter LPM3 w/ interrupt
_BIS_SR(GIE);
while(1)
{};
}
// Timer A0 interrupt service routine
#pragma vector=TIMERA0_VECTOR
__interrupt void Timer_A (void)
{
P1OUT ^= 0x01;
if( (TACTL & TAIFG)== 0x0000) // count how many times we
temp++; // do not find the TAIFG
set
TACTL &= ~TAIFG;
TACCTL2 &= ~CCIFG;
TACCTL1 &= ~CCIFG;
}
Reply by ●September 9, 20052005-09-09
The following program has been used to verify the Timer A TAIFG operation.
It is a modified version of
a TI supplied sample code.
The Results indicate a problem with either the USB FET or the IAR Interface.
A scope has been attached to P1.01 to observe the output waveform.
There have been run two tests, one under the IAR program control, the other
with
the FET disconnected and power applied from 2 "D" batteries.
With the FET connected and with IAR in debug "GO" mode the resulting
waveform was extremely
jittery, while when the run with the FET disconnected showed a clean and
stable waveform.
This indicates that while the program is run under the IAR Debug control
some Interrupts were missed.
A run to breakpoint set to the first instruction in the ISR showed always
that the first time thru it,
the TAIFG is never set while the TAR was equal to CCR0!
The "temp" counter is breakpoint and it will stop the run every 2, 5
minutes indicating an mised TAIFG.
In conclusion, TI Docs are right ! TAIFG is a STICKY flag that needs to be
reset at the end of the ISR.
A small note. when Timer A is used in this mode (Continuous UP) load not
only CCR0 but also CCR1 @ CCR2 with some dummy values. Otherwise
the corresponding CCIFG will also be set because the CCRn are reset to
zero at reset (TAR becomes zero after counting to CCR0)
Conclusion. Do not trust the USBFET combination and IAR. Between these two,
I lost about 2 days tracking down this problem.
Alex
===========================================================================//**************************************************************************
****
// MSP-FET430P140 Demo - Timer_A, Toggle P1.0, CCR0 Up Mode ISR, 32kHz ACLK
//
// Description: Toggle P1.0 using software and the TA_0 ISR. Timer_A is
// configured for up mode, thus the timer overflows when TAR counts
// to CCR0. In this example, CCR0 is loaded with 1000-1.
// Toggle rate = 32768/(2*1000) = 16.384
// ACLK = TACLK = 32768Hz, MCLK = SMCLK = default DCO ~800kHz
// //* An external watch crystal on XIN XOUT is required for ACLK *//
//
// MSP430F149
// ---------------
// /|\| XIN|-
// | | | 32kHz
// --|RST XOUT|-
// | |
// | P1.0|-->LED
//
// M. Buccini
// Texas Instruments Inc.
// Feb 2005
// Built with IAR Embedded Workbench Version: 3.21A
//**************************************************************************
****
#include <msp430x16x.h>
int temp;
void main(void)
{
temp=0;
WDTCTL = WDTPW + WDTHOLD; // Stop WDT
P1DIR |= 0x01; // P1.0 output
CCTL0 = CCIE; // CCR0 interrupt enabled
CCR0 = 0x7fff;
CCR1 = 0x9000;
CCR2 = 0xa000;
TACTL = TASSEL_1 + MC_1; // ACLK, upmode
//_BIS_SR(LPM3_bits + GIE); // Enter LPM3 w/ interrupt
_BIS_SR(GIE);
while(1)
{};
}
// Timer A0 interrupt service routine
#pragma vector=TIMERA0_VECTOR
__interrupt void Timer_A (void)
{
int i;
i++;
if( (TACTL & TAIFG)== 0x0000) // count how many times we
{
temp++; // do not find the
TAIFG set
P1OUT ^= 0x01;
}
TACTL &= ~TAIFG;
TACCTL2 &= ~CCIFG;
TACCTL1 &= ~CCIFG;
}
