Progress: (Originally 5419A Timer problem and 8KB KickStart limit)

8K Kickstart limit: Resolved.
Timer problem: Unresolved.

The timer problem is now driving me crazy.

I have two programming environments that are closely related. Each uses the KickStart for MSP430 Version 5.4 tools. One is entirely within Kickstart, the other is outside of Kickstart.

Environment 1: Kickstart
Assembler: a430.exe version 4.21.2 contained within KickStart.
Linker: xlink.exe version 4.6.10 contained within Kickstart.
Programmer: IAR CSpy debugger.
JTAG pod: MSP-FET430UIF running firmware version 2.04.01.004.

In this environment, I can assemble the program and load it into my target board via the JTAG port using the Debug and Download mode.
In debug, I release the program to run via "Go" and everything runs fine. I can exit the debugger, remove the JTAG cable and re-power my board and everything still runs as designed. I have a linker option enabled to produce an extra output file in intel hex format.

Environment 2: Discrete tools.
Assembler: a430.exe from KickStart above via command line.
Linker: xlink.exe from KickStart above via command line.
Programmer: Elprotronics FET-Pro430 Lite version 3.0-6.
JTAG pod: A different MSP-FET430UIF running firmware 3.02.03.015.

In this environment, the program is executed via a Bat file and produces an intel hex format file that is then loaded by the Elprotronic programmer via the second "upgraded" FET430UIF into the target board. This hex file is identical to the extra output file produced by Environment #1.

The only differences that I see are in the method of programming and the JTAG pods.

All previous code ran correctly until the Timer A0 routine was added.
I have a short test routine accessed by command over the serial port.
In the working version, pressing a key results in a 100 ms pulse on an output pin. In the failing version, it appears that the Timer is never being clocked. (ACLK from 32.768 KH XT1 source). ACLK is being output on an ACLK port pin.

Code is essentially:
1) Initialize timer to reset conditions. i.e. Stopped/Cleared/Mode 0.
2) Initialize Capture Compare register 0 to 0x0000.
3) Enable CCR0 interrupts.
4) Set MC mode to count up to CCR0.
5) Load CCR0 interval, effectively starting counter.
6) Drop port pin 3.0 low.
7) Wait for Interval complete.
8) Set port pin 3.0 high.

In the TA0 Source 0 ISR, we simply set a Flag detectable in the
foreground.

Since the code runs in one environment but not in the other, I assume that it is not the cause of the problem, but the target of some other problem.

CSpy is evidently adding something to the mix that I need to include in my standalone environment.

Any idea(s)?

Blakely

--- In m..., "Blakely" wrote:
>
> I am bringing up a new design, based on the MSP430F5419A and have run into an unusual problem.
>
> I have ported over a non interrupt driven timer wait routine that uses TA0. It runs on a F148 part, but not on the 5419A. I have tried it with both SMCLK and ACLK, both of which are output on port pins, so I can see them running. Everything else runs just fine.
>
> It appears that the TA0 is not being clocked in that it never increments and the value in CCR0 is never reached and CCIF is never set. MC bits are non zero. Mode is 01 = Count up to CCR0 limit which should set CCIF when reached.
>
> I did load a scaled back version using the IAR CSpy, and only once did it run using ACLK. This makes me think that the stepping mode of the debugger may be enabling something that is normally not enabled. Any ideas? I don't have that much hair left to lose.
>
> Did anyone find a solution to the new 8K limit in the IAR download/debug? Kind of silly to suddenly start limiting that. I did a search for an earlier version of KickStart that perhaps did not have that limitation. Anyone have a working version they can send me?
>
> Blakely
>

Start a New Thread

I don't know why thisa would be different in the two environments, but
the method, as you describe it, fo initialisinging the timer is wrong.

Code is essentially:
1) Initialize timer to reset conditions. i.e. Stopped/Cleared/Mode 0.
2) Initialize Capture Compare register 0 to 0x0000.

At this point CCIFG in CCTLA0 will be set

3) Enable CCR0 interrupts.

You have effectively enabled a CCRA0 interrupt on compare, the compare value is 0, the count to value is 0, the counter behaviour is not to run, probably, but to stall on 0 generating interrupts. There is also likely to be an interrupt pending from POR

4) Set MC mode to count up to CCR0.

You should have initialised the count to value first, before enabling the timer or interrupts, then cleared the pending interrupt flag, before enabling the interrupt

5) Load CCR0 interval, effectively starting counter.

No, the counter starts when you clear the reset bit TACLR, whether it's doing what you expect is a totally different thing

6) Drop port pin 3.0 low.
7) Wait for Interval complete.
8) Set port pin 3.0 high.

You are enabling the interrupts before you have initialised their values. The sequence I use is:-

MOV #TICKRATE,&CCRA0 ;TIMER A 1 SECOND INTERRUPT
MOV #MC_2+TASSEL_1+TACLR+ID_3,&TACTL;ACLK, CONTINUOUS MODE, OVF DISABLED
BIC #CCIFG,&CCTLA0 ;ENABLE TIMERA0 FOR 1 SECOND TICK
BIS #CCIE,&CCTLA0 ;ENABLE TIMERA0 FOR 1 SECOND TICK

Al

On 14/05/2012 1:24 AM, Blakely wrote:
> Progress: (Originally 5419A Timer problem and 8KB KickStart limit)
>
> 8K Kickstart limit: Resolved.
> Timer problem: Unresolved.
>
> The timer problem is now driving me crazy.
>
> I have two programming environments that are closely related. Each uses the KickStart for MSP430 Version 5.4 tools. One is entirely within Kickstart, the other is outside of Kickstart.
>
> Environment 1: Kickstart
> Assembler: a430.exe version 4.21.2 contained within KickStart.
> Linker: xlink.exe version 4.6.10 contained within Kickstart.
> Programmer: IAR CSpy debugger.
> JTAG pod: MSP-FET430UIF running firmware version 2.04.01.004.
>
> In this environment, I can assemble the program and load it into my target board via the JTAG port using the Debug and Download mode.
> In debug, I release the program to run via "Go" and everything runs fine. I can exit the debugger, remove the JTAG cable and re-power my board and everything still runs as designed. I have a linker option enabled to produce an extra output file in intel hex format.
>
> Environment 2: Discrete tools.
> Assembler: a430.exe from KickStart above via command line.
> Linker: xlink.exe from KickStart above via command line.
> Programmer: Elprotronics FET-Pro430 Lite version 3.0-6.
> JTAG pod: A different MSP-FET430UIF running firmware 3.02.03.015.
>
> In this environment, the program is executed via a Bat file and produces an intel hex format file that is then loaded by the Elprotronic programmer via the second "upgraded" FET430UIF into the target board. This hex file is identical to the extra output file produced by Environment #1.
>
> The only differences that I see are in the method of programming and the JTAG pods.
>
> All previous code ran correctly until the Timer A0 routine was added.
> I have a short test routine accessed by command over the serial port.
> In the working version, pressing a key results in a 100 ms pulse on an output pin. In the failing version, it appears that the Timer is never being clocked. (ACLK from 32.768 KH XT1 source). ACLK is being output on an ACLK port pin.
>
> Code is essentially:
> 1) Initialize timer to reset conditions. i.e. Stopped/Cleared/Mode 0.
> 2) Initialize Capture Compare register 0 to 0x0000.
> 3) Enable CCR0 interrupts.
> 4) Set MC mode to count up to CCR0.
> 5) Load CCR0 interval, effectively starting counter.
> 6) Drop port pin 3.0 low.
> 7) Wait for Interval complete.
> 8) Set port pin 3.0 high.
>
> In the TA0 Source 0 ISR, we simply set a Flag detectable in the
> foreground.
>
> Since the code runs in one environment but not in the other, I assume that it is not the cause of the problem, but the target of some other problem.
>
> CSpy is evidently adding something to the mix that I need to include in my standalone environment.
>
> Any idea(s)?
>
> Blakely
> --- In m..., "Blakely" wrote:
>> I am bringing up a new design, based on the MSP430F5419A and have run into an unusual problem.
>>
>> I have ported over a non interrupt driven timer wait routine that uses TA0. It runs on a F148 part, but not on the 5419A. I have tried it with both SMCLK and ACLK, both of which are output on port pins, so I can see them running. Everything else runs just fine.
>>
>> It appears that the TA0 is not being clocked in that it never increments and the value in CCR0 is never reached and CCIF is never set. MC bits are non zero. Mode is 01 = Count up to CCR0 limit which should set CCIF when reached.
>>
>> I did load a scaled back version using the IAR CSpy, and only once did it run using ACLK. This makes me think that the stepping mode of the debugger may be enabling something that is normally not enabled. Any ideas? I don't have that much hair left to lose.
>>
>> Did anyone find a solution to the new 8K limit in the IAR download/debug? Kind of silly to suddenly start limiting that. I did a search for an earlier version of KickStart that perhaps did not have that limitation. Anyone have a working version they can send me?
>>
>> Blakely
>> Start a New Thread

Al

Thanks for the quick response! You are a great resource.

I have some more information that is independent of the code issues.

First I used the Elprotronics programmer to pull back the code images of
the working code and the non working code. These come back as text
files and so they are easy to check against each other. They Match!
Now the last remaining hairs from my head are gone. Crazy.

It gets better: I used the failing environment to program the target
board. Main body of code appears to run fine. I enter the command to
test the Timer code and as expected, it fails. I removed the JTAG
cable, remove power, reapply power. Main body of code again appears to
run fine. I enter the command to test the Timer code and this time It
Works.

The conclusion I draw is that "updated" MSP-FET430UIF JTAG port
used with the Elprotronics program is somehow interfering with the ACLK
reaching the timer. If I program the target and leave the JTAG cable
connected, the test routine fails. With the JTAG removed, the test
routine runs.

The pins used by the JTAG are available as general port pins and are
assigned as inputs. There is a bit in the System Control Register (bit
5 = SYSJTAGPIN, cleared after a BOR) that I have left in the Shared
(=0) state. I will try it again and see if the problem goes away when
setting it to Dedicated (=1)

The code example was the last of a dozen variations I used trying to
find something that work. Hacked in the extreme. When something finally
worked, I left it as it was and moved on to what was different.

Blakely
--- In m..., Onestone wrote:
>
> I don't know why thisa would be different in the two environments, but
> the method, as you describe it, fo initialisinging the timer is wrong.
>
> Code is essentially:
> 1) Initialize timer to reset conditions. i.e. Stopped/Cleared/Mode 0.
> 2) Initialize Capture Compare register 0 to 0x0000.
>
> At this point CCIFG in CCTLA0 will be set
>
> 3) Enable CCR0 interrupts.
>
> You have effectively enabled a CCRA0 interrupt on compare, the compare
value is 0, the count to value is 0, the counter behaviour is not to
run, probably, but to stall on 0 generating interrupts. There is also
likely to be an interrupt pending from POR
>
> 4) Set MC mode to count up to CCR0.
>
> You should have initialised the count to value first, before enabling
the timer or interrupts, then cleared the pending interrupt flag, before
enabling the interrupt
>
> 5) Load CCR0 interval, effectively starting counter.
>
> No, the counter starts when you clear the reset bit TACLR, whether
it's doing what you expect is a totally different thing
>
> 6) Drop port pin 3.0 low.
> 7) Wait for Interval complete.
> 8) Set port pin 3.0 high.
>
> You are enabling the interrupts before you have initialised their
values. The sequence I use is:-
>
> MOV #TICKRATE,&CCRA0 ;TIMER A 1 SECOND INTERRUPT
> MOV #MC_2+TASSEL_1+TACLR+ID_3,&TACTL;ACLK, CONTINUOUS MODE, OVF
DISABLED
> BIC #CCIFG,&CCTLA0 ;ENABLE TIMERA0 FOR 1 SECOND TICK
> BIS #CCIE,&CCTLA0 ;ENABLE TIMERA0 FOR 1 SECOND TICK
>
> Al
> On 14/05/2012 1:24 AM, Blakely wrote:
> > Progress: (Originally 5419A Timer problem and 8KB KickStart limit)
> >
> > 8K Kickstart limit: Resolved.
> > Timer problem: Unresolved.
> >
> > The timer problem is now driving me crazy.
> >
> > I have two programming environments that are closely related. Each
uses the KickStart for MSP430 Version 5.4 tools. One is entirely within
Kickstart, the other is outside of Kickstart.
> >
> > Environment 1: Kickstart
> > Assembler: a430.exe version 4.21.2 contained within KickStart.
> > Linker: xlink.exe version 4.6.10 contained within Kickstart.
> > Programmer: IAR CSpy debugger.
> > JTAG pod: MSP-FET430UIF running firmware version 2.04.01.004.
> >
> > In this environment, I can assemble the program and load it into my
target board via the JTAG port using the Debug and Download mode.
> > In debug, I release the program to run via "Go" and everything runs
fine. I can exit the debugger, remove the JTAG cable and re-power my
board and everything still runs as designed. I have a linker option
enabled to produce an extra output file in intel hex format.
> >
> > Environment 2: Discrete tools.
> > Assembler: a430.exe from KickStart above via command line.
> > Linker: xlink.exe from KickStart above via command line.
> > Programmer: Elprotronics FET-Pro430 Lite version 3.0-6.
> > JTAG pod: A different MSP-FET430UIF running firmware 3.02.03.015.
> >
> > In this environment, the program is executed via a Bat file and
produces an intel hex format file that is then loaded by the Elprotronic
programmer via the second "upgraded" FET430UIF into the target board.
This hex file is identical to the extra output file produced by
Environment #1.
> >
> > The only differences that I see are in the method of programming and
the JTAG pods.
> >
> > All previous code ran correctly until the Timer A0 routine was
added.
> > I have a short test routine accessed by command over the serial
port.
> > In the working version, pressing a key results in a 100 ms pulse on
an output pin. In the failing version, it appears that the Timer is
never being clocked. (ACLK from 32.768 KH XT1 source). ACLK is being
output on an ACLK port pin.
> >
> > Code is essentially:
> > 1) Initialize timer to reset conditions. i.e. Stopped/Cleared/Mode
0.
> > 2) Initialize Capture Compare register 0 to 0x0000.
> > 3) Enable CCR0 interrupts.
> > 4) Set MC mode to count up to CCR0.
> > 5) Load CCR0 interval, effectively starting counter.
> > 6) Drop port pin 3.0 low.
> > 7) Wait for Interval complete.
> > 8) Set port pin 3.0 high.
> >
> > In the TA0 Source 0 ISR, we simply set a Flag detectable in the
> > foreground.
> >
> > Since the code runs in one environment but not in the other, I
assume that it is not the cause of the problem, but the target of some
other problem.
> >
> > CSpy is evidently adding something to the mix that I need to include
in my standalone environment.
> >
> > Any idea(s)?
> >
> > Blakely
> >
> >
> >
> >
> > --- In m..., "Blakely"blakely.lacroix@ wrote:
> >> I am bringing up a new design, based on the MSP430F5419A and have
run into an unusual problem.
> >>
> >> I have ported over a non interrupt driven timer wait routine that
uses TA0. It runs on a F148 part, but not on the 5419A. I have tried
it with both SMCLK and ACLK, both of which are output on port pins, so I
can see them running. Everything else runs just fine.
> >>
> >> It appears that the TA0 is not being clocked in that it never
increments and the value in CCR0 is never reached and CCIF is never set.
MC bits are non zero. Mode is 01 = Count up to CCR0 limit which should
set CCIF when reached.
> >>
> >> I did load a scaled back version using the IAR CSpy, and only once
did it run using ACLK. This makes me think that the stepping mode of
the debugger may be enabling something that is normally not enabled.
Any ideas? I don't have that much hair left to lose.
> >>
> >> Did anyone find a solution to the new 8K limit in the IAR
download/debug? Kind of silly to suddenly start limiting that. I did a
search for an earlier version of KickStart that perhaps did not have
that limitation. Anyone have a working version they can send me?
> >>
> >> Blakely
> >>
> >
> >
> >
> >
> >
> >
> >
> > Start a New Thread

I now have Al's code in place. Same result.
Makes no difference if we select Timer A0 or Timer A1 or use ACLK or SMCLK. If the JTAG cable is in place after a reset, the Timers do not run. This appears to be true even after I exit the Elprotronics program. Remove the JTAG cable, PUC the device and they run.

I will double check my hardware connections and add another source of reset - DTR on a Port 1 pin and see if it is related to PUC or other.

The mystery continues.

Blakely

--- In m..., "Blakely" wrote:
>
> Al
>
> Thanks for the quick response! You are a great resource.
>
> I have some more information that is independent of the code issues.
>
> First I used the Elprotronics programmer to pull back the code images of
> the working code and the non working code. These come back as text
> files and so they are easy to check against each other. They Match!
> Now the last remaining hairs from my head are gone. Crazy.
>
> It gets better: I used the failing environment to program the target
> board. Main body of code appears to run fine. I enter the command to
> test the Timer code and as expected, it fails. I removed the JTAG
> cable, remove power, reapply power. Main body of code again appears to
> run fine. I enter the command to test the Timer code and this time It
> Works.
>
> The conclusion I draw is that "updated" MSP-FET430UIF JTAG port
> used with the Elprotronics program is somehow interfering with the ACLK
> reaching the timer. If I program the target and leave the JTAG cable
> connected, the test routine fails. With the JTAG removed, the test
> routine runs.
>
> The pins used by the JTAG are available as general port pins and are
> assigned as inputs. There is a bit in the System Control Register (bit
> 5 = SYSJTAGPIN, cleared after a BOR) that I have left in the Shared
> (=0) state. I will try it again and see if the problem goes away when
> setting it to Dedicated (=1)
>
> The code example was the last of a dozen variations I used trying to
> find something that work. Hacked in the extreme. When something finally
> worked, I left it as it was and moved on to what was different.
>
> Blakely
> --- In m..., Onestone wrote:
> >
> > I don't know why thisa would be different in the two environments, but
> > the method, as you describe it, fo initialisinging the timer is wrong.
> >
> > Code is essentially:
> > 1) Initialize timer to reset conditions. i.e. Stopped/Cleared/Mode 0.
> > 2) Initialize Capture Compare register 0 to 0x0000.
> >
> > At this point CCIFG in CCTLA0 will be set
> >
> > 3) Enable CCR0 interrupts.
> >
> > You have effectively enabled a CCRA0 interrupt on compare, the compare
> value is 0, the count to value is 0, the counter behaviour is not to
> run, probably, but to stall on 0 generating interrupts. There is also
> likely to be an interrupt pending from POR
> >
> > 4) Set MC mode to count up to CCR0.
> >
> > You should have initialised the count to value first, before enabling
> the timer or interrupts, then cleared the pending interrupt flag, before
> enabling the interrupt
> >
> > 5) Load CCR0 interval, effectively starting counter.
> >
> > No, the counter starts when you clear the reset bit TACLR, whether
> it's doing what you expect is a totally different thing
> >
> > 6) Drop port pin 3.0 low.
> > 7) Wait for Interval complete.
> > 8) Set port pin 3.0 high.
> >
> > You are enabling the interrupts before you have initialised their
> values. The sequence I use is:-
> >
> > MOV #TICKRATE,&CCRA0 ;TIMER A 1 SECOND INTERRUPT
> > MOV #MC_2+TASSEL_1+TACLR+ID_3,&TACTL;ACLK, CONTINUOUS MODE, OVF
> DISABLED
> > BIC #CCIFG,&CCTLA0 ;ENABLE TIMERA0 FOR 1 SECOND TICK
> > BIS #CCIE,&CCTLA0 ;ENABLE TIMERA0 FOR 1 SECOND TICK
> >
> > Al
> >
> >
> >
> >
> > On 14/05/2012 1:24 AM, Blakely wrote:
> > > Progress: (Originally 5419A Timer problem and 8KB KickStart limit)
> > >
> > > 8K Kickstart limit: Resolved.
> > > Timer problem: Unresolved.
> > >
> > > The timer problem is now driving me crazy.
> > >
> > > I have two programming environments that are closely related. Each
> uses the KickStart for MSP430 Version 5.4 tools. One is entirely within
> Kickstart, the other is outside of Kickstart.
> > >
> > > Environment 1: Kickstart
> > > Assembler: a430.exe version 4.21.2 contained within KickStart.
> > > Linker: xlink.exe version 4.6.10 contained within Kickstart.
> > > Programmer: IAR CSpy debugger.
> > > JTAG pod: MSP-FET430UIF running firmware version 2.04.01.004.
> > >
> > > In this environment, I can assemble the program and load it into my
> target board via the JTAG port using the Debug and Download mode.
> > > In debug, I release the program to run via "Go" and everything runs
> fine. I can exit the debugger, remove the JTAG cable and re-power my
> board and everything still runs as designed. I have a linker option
> enabled to produce an extra output file in intel hex format.
> > >
> > > Environment 2: Discrete tools.
> > > Assembler: a430.exe from KickStart above via command line.
> > > Linker: xlink.exe from KickStart above via command line.
> > > Programmer: Elprotronics FET-Pro430 Lite version 3.0-6.
> > > JTAG pod: A different MSP-FET430UIF running firmware 3.02.03.015.
> > >
> > > In this environment, the program is executed via a Bat file and
> produces an intel hex format file that is then loaded by the Elprotronic
> programmer via the second "upgraded" FET430UIF into the target board.
> This hex file is identical to the extra output file produced by
> Environment #1.
> > >
> > > The only differences that I see are in the method of programming and
> the JTAG pods.
> > >
> > > All previous code ran correctly until the Timer A0 routine was
> added.
> > > I have a short test routine accessed by command over the serial
> port.
> > > In the working version, pressing a key results in a 100 ms pulse on
> an output pin. In the failing version, it appears that the Timer is
> never being clocked. (ACLK from 32.768 KH XT1 source). ACLK is being
> output on an ACLK port pin.
> > >
> > > Code is essentially:
> > > 1) Initialize timer to reset conditions. i.e. Stopped/Cleared/Mode
> 0.
> > > 2) Initialize Capture Compare register 0 to 0x0000.
> > > 3) Enable CCR0 interrupts.
> > > 4) Set MC mode to count up to CCR0.
> > > 5) Load CCR0 interval, effectively starting counter.
> > > 6) Drop port pin 3.0 low.
> > > 7) Wait for Interval complete.
> > > 8) Set port pin 3.0 high.
> > >
> > > In the TA0 Source 0 ISR, we simply set a Flag detectable in the
> > > foreground.
> > >
> > > Since the code runs in one environment but not in the other, I
> assume that it is not the cause of the problem, but the target of some
> other problem.
> > >
> > > CSpy is evidently adding something to the mix that I need to include
> in my standalone environment.
> > >
> > > Any idea(s)?
> > >
> > > Blakely
> > >
> > >
> > >
> > >
> > > --- In m..., "Blakely"blakely.lacroix@ wrote:
> > >> I am bringing up a new design, based on the MSP430F5419A and have
> run into an unusual problem.
> > >>
> > >> I have ported over a non interrupt driven timer wait routine that
> uses TA0. It runs on a F148 part, but not on the 5419A. I have tried
> it with both SMCLK and ACLK, both of which are output on port pins, so I
> can see them running. Everything else runs just fine.
> > >>
> > >> It appears that the TA0 is not being clocked in that it never
> increments and the value in CCR0 is never reached and CCIF is never set.
> MC bits are non zero. Mode is 01 = Count up to CCR0 limit which should
> set CCIF when reached.
> > >>
> > >> I did load a scaled back version using the IAR CSpy, and only once
> did it run using ACLK. This makes me think that the stepping mode of
> the debugger may be enabling something that is normally not enabled.
> Any ideas? I don't have that much hair left to lose.
> > >>
> > >> Did anyone find a solution to the new 8K limit in the IAR
> download/debug? Kind of silly to suddenly start limiting that. I did a
> search for an earlier version of KickStart that perhaps did not have
> that limitation. Anyone have a working version they can send me?
> > >>
> > >> Blakely
> > >>
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > Start a New Thread

Putting the JTAG pins in dedicated mode (SYSJTAGPIN=1) will cause problems with some programming tools that expect the target to have shared pins. I found this out with the REP430 (Replicator). If the JTAG pins are in the dedicated mode, the JTAG sequence used to retrieve the CoreId does not work. Normally the I/O pins are switched to JTAG mode using the TEST signal. I had to chage the sequence to retrieve the CoreId first with the TEST signal high and if that failed to drop the TEST signal and try again. The TEST signal was not used in the 1xx series, but is required for the 5xx series with shared I/O pins.
----- Original Message -----
From: Blakely
To: m...
Sent: Sunday, May 13, 2012 11:52 AM
Subject: [msp430] Re: MSP430 F 5438A Timer / Environment issue. Very Weird.

I now have Al's code in place. Same result.
Makes no difference if we select Timer A0 or Timer A1 or use ACLK or SMCLK. If the JTAG cable is in place after a reset, the Timers do not run. This appears to be true even after I exit the Elprotronics program. Remove the JTAG cable, PUC the device and they run.

I will double check my hardware connections and add another source of reset - DTR on a Port 1 pin and see if it is related to PUC or other.

The mystery continues.

Blakely

--- In m..., "Blakely" wrote:
>
> Al
>
> Thanks for the quick response! You are a great resource.
>
> I have some more information that is independent of the code issues.
>
> First I used the Elprotronics programmer to pull back the code images of
> the working code and the non working code. These come back as text
> files and so they are easy to check against each other. They Match!
> Now the last remaining hairs from my head are gone. Crazy.
>
> It gets better: I used the failing environment to program the target
> board. Main body of code appears to run fine. I enter the command to
> test the Timer code and as expected, it fails. I removed the JTAG
> cable, remove power, reapply power. Main body of code again appears to
> run fine. I enter the command to test the Timer code and this time It
> Works.
>
> The conclusion I draw is that "updated" MSP-FET430UIF JTAG port
> used with the Elprotronics program is somehow interfering with the ACLK
> reaching the timer. If I program the target and leave the JTAG cable
> connected, the test routine fails. With the JTAG removed, the test
> routine runs.
>
> The pins used by the JTAG are available as general port pins and are
> assigned as inputs. There is a bit in the System Control Register (bit
> 5 = SYSJTAGPIN, cleared after a BOR) that I have left in the Shared
> (=0) state. I will try it again and see if the problem goes away when
> setting it to Dedicated (=1)
>
> The code example was the last of a dozen variations I used trying to
> find something that work. Hacked in the extreme. When something finally
> worked, I left it as it was and moved on to what was different.
>
> Blakely
>
>
> --- In m..., Onestone wrote:
> >
> > I don't know why thisa would be different in the two environments, but
> > the method, as you describe it, fo initialisinging the timer is wrong.
> >
> > Code is essentially:
> > 1) Initialize timer to reset conditions. i.e. Stopped/Cleared/Mode 0.
> > 2) Initialize Capture Compare register 0 to 0x0000.
> >
> > At this point CCIFG in CCTLA0 will be set
> >
> > 3) Enable CCR0 interrupts.
> >
> > You have effectively enabled a CCRA0 interrupt on compare, the compare
> value is 0, the count to value is 0, the counter behaviour is not to
> run, probably, but to stall on 0 generating interrupts. There is also
> likely to be an interrupt pending from POR
> >
> > 4) Set MC mode to count up to CCR0.
> >
> > You should have initialised the count to value first, before enabling
> the timer or interrupts, then cleared the pending interrupt flag, before
> enabling the interrupt
> >
> > 5) Load CCR0 interval, effectively starting counter.
> >
> > No, the counter starts when you clear the reset bit TACLR, whether
> it's doing what you expect is a totally different thing
> >
> > 6) Drop port pin 3.0 low.
> > 7) Wait for Interval complete.
> > 8) Set port pin 3.0 high.
> >
> > You are enabling the interrupts before you have initialised their
> values. The sequence I use is:-
> >
> > MOV #TICKRATE,&CCRA0 ;TIMER A 1 SECOND INTERRUPT
> > MOV #MC_2+TASSEL_1+TACLR+ID_3,&TACTL;ACLK, CONTINUOUS MODE, OVF
> DISABLED
> > BIC #CCIFG,&CCTLA0 ;ENABLE TIMERA0 FOR 1 SECOND TICK
> > BIS #CCIE,&CCTLA0 ;ENABLE TIMERA0 FOR 1 SECOND TICK
> >
> > Al
> >
> >
> >
> >
> > On 14/05/2012 1:24 AM, Blakely wrote:
> > > Progress: (Originally 5419A Timer problem and 8KB KickStart limit)
> > >
> > > 8K Kickstart limit: Resolved.
> > > Timer problem: Unresolved.
> > >
> > > The timer problem is now driving me crazy.
> > >
> > > I have two programming environments that are closely related. Each
> uses the KickStart for MSP430 Version 5.4 tools. One is entirely within
> Kickstart, the other is outside of Kickstart.
> > >
> > > Environment 1: Kickstart
> > > Assembler: a430.exe version 4.21.2 contained within KickStart.
> > > Linker: xlink.exe version 4.6.10 contained within Kickstart.
> > > Programmer: IAR CSpy debugger.
> > > JTAG pod: MSP-FET430UIF running firmware version 2.04.01.004.
> > >
> > > In this environment, I can assemble the program and load it into my
> target board via the JTAG port using the Debug and Download mode.
> > > In debug, I release the program to run via "Go" and everything runs
> fine. I can exit the debugger, remove the JTAG cable and re-power my
> board and everything still runs as designed. I have a linker option
> enabled to produce an extra output file in intel hex format.
> > >
> > > Environment 2: Discrete tools.
> > > Assembler: a430.exe from KickStart above via command line.
> > > Linker: xlink.exe from KickStart above via command line.
> > > Programmer: Elprotronics FET-Pro430 Lite version 3.0-6.
> > > JTAG pod: A different MSP-FET430UIF running firmware 3.02.03.015.
> > >
> > > In this environment, the program is executed via a Bat file and
> produces an intel hex format file that is then loaded by the Elprotronic
> programmer via the second "upgraded" FET430UIF into the target board.
> This hex file is identical to the extra output file produced by
> Environment #1.
> > >
> > > The only differences that I see are in the method of programming and
> the JTAG pods.
> > >
> > > All previous code ran correctly until the Timer A0 routine was
> added.
> > > I have a short test routine accessed by command over the serial
> port.
> > > In the working version, pressing a key results in a 100 ms pulse on
> an output pin. In the failing version, it appears that the Timer is
> never being clocked. (ACLK from 32.768 KH XT1 source). ACLK is being
> output on an ACLK port pin.
> > >
> > > Code is essentially:
> > > 1) Initialize timer to reset conditions. i.e. Stopped/Cleared/Mode
> 0.
> > > 2) Initialize Capture Compare register 0 to 0x0000.
> > > 3) Enable CCR0 interrupts.
> > > 4) Set MC mode to count up to CCR0.
> > > 5) Load CCR0 interval, effectively starting counter.
> > > 6) Drop port pin 3.0 low.
> > > 7) Wait for Interval complete.
> > > 8) Set port pin 3.0 high.
> > >
> > > In the TA0 Source 0 ISR, we simply set a Flag detectable in the
> > > foreground.
> > >
> > > Since the code runs in one environment but not in the other, I
> assume that it is not the cause of the problem, but the target of some
> other problem.
> > >
> > > CSpy is evidently adding something to the mix that I need to include
> in my standalone environment.
> > >
> > > Any idea(s)?
> > >
> > > Blakely
> > >
> > >
> > >
> > >
> > > --- In m..., "Blakely"blakely.lacroix@ wrote:
> > >> I am bringing up a new design, based on the MSP430F5419A and have
> run into an unusual problem.
> > >>
> > >> I have ported over a non interrupt driven timer wait routine that
> uses TA0. It runs on a F148 part, but not on the 5419A. I have tried
> it with both SMCLK and ACLK, both of which are output on port pins, so I
> can see them running. Everything else runs just fine.
> > >>
> > >> It appears that the TA0 is not being clocked in that it never
> increments and the value in CCR0 is never reached and CCIF is never set.
> MC bits are non zero. Mode is 01 = Count up to CCR0 limit which should
> set CCIF when reached.
> > >>
> > >> I did load a scaled back version using the IAR CSpy, and only once
> did it run using ACLK. This makes me think that the stepping mode of
> the debugger may be enabling something that is normally not enabled.
> Any ideas? I don't have that much hair left to lose.
> > >>
> > >> Did anyone find a solution to the new 8K limit in the IAR
> download/debug? Kind of silly to suddenly start limiting that. I did a
> search for an earlier version of KickStart that perhaps did not have
> that limitation. Anyone have a working version they can send me?
> > >>
> > >> Blakely
> > >>
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > Start a New Thread

We were running with the reset value of SYSJTAGPIN (=0). We then actively zeroed zero that bit as part of the bring up just to be sure. No change.

If we power the target board with the JTAG pod (Power in JTAG pin 2) and program the target using the Elprotronics programmer (EP), the unit fails until we toggle the power to the target. If we just issue a Reset (both of these activated by the EP buttons), we also fail.

We then added support to use the loss of Terminal DTR to invoke a Port 1.7 interrupt. The P1.7 ISR opens the PMMR, sets the PMMSWPOR closes the PMMR and does a RETI (just in case it actually take some time for the POR to be recognized. A Terminal Disconnect (Hangup) invokes the interrupt. Part is reset. Timer is still non operational.

If I program the part using the EP, leave the JTAG cable attached (Target power out JTAG pin 4) the Timer will fail. If I cycle the external power on the target board, the Timer works.

Basically, I need a complete removal of power from the board after programming with the EP to get the Timer to run. During all of these tests above, ACLK was still visible and active on a ACLK output pin.

From the evidence collected so far, I believe it has to do with the just the MSP-FET430UIF. The one used with the EP programmer was "updated" while the one used with the IAR debugger was the standard issue. Unfortunatly, the standard issue is no longer standard in that we did have the option under IAR (exercised) to do an update as well.

Since I actually have to produce something and do have a workaround (repower the target board), I will move on. I hate fighting with the tools. This reduces confidence overall. There are enough potential gotchas out there. Tools should not be one of them.

This post can serve as a searchable marker for other who might run into this problem. But something is not quite right with the EP and the JTAG port. I will double check the TI errata on this. Maybe it is a new event.

Thanks to Steve and Al for support on Mother's Day.

Blakely

--- In m..., "Steve Mayfield" wrote:
>
> Putting the JTAG pins in dedicated mode (SYSJTAGPIN=1) will cause problems with some programming tools that expect the target to have shared pins. I found this out with the REP430 (Replicator). If the JTAG pins are in the dedicated mode, the JTAG sequence used to retrieve the CoreId does not work. Normally the I/O pins are switched to JTAG mode using the TEST signal. I had to chage the sequence to retrieve the CoreId first with the TEST signal high and if that failed to drop the TEST signal and try again. The TEST signal was not used in the 1xx series, but is required for the 5xx series with shared I/O pins.
> ----- Original Message -----
> From: Blakely
> To: m...
> Sent: Sunday, May 13, 2012 11:52 AM
> Subject: [msp430] Re: MSP430 F 5438A Timer / Environment issue. Very Weird.
>
> I now have Al's code in place. Same result.
> Makes no difference if we select Timer A0 or Timer A1 or use ACLK or SMCLK. If the JTAG cable is in place after a reset, the Timers do not run. This appears to be true even after I exit the Elprotronics program. Remove the JTAG cable, PUC the device and they run.
>
> I will double check my hardware connections and add another source of reset - DTR on a Port 1 pin and see if it is related to PUC or other.
>
> The mystery continues.
>
> Blakely
>
> --- In m..., "Blakely" wrote:
> >
> > Al
> >
> > Thanks for the quick response! You are a great resource.
> >
> > I have some more information that is independent of the code issues.
> >
> > First I used the Elprotronics programmer to pull back the code images of
> > the working code and the non working code. These come back as text
> > files and so they are easy to check against each other. They Match!
> > Now the last remaining hairs from my head are gone. Crazy.
> >
> > It gets better: I used the failing environment to program the target
> > board. Main body of code appears to run fine. I enter the command to
> > test the Timer code and as expected, it fails. I removed the JTAG
> > cable, remove power, reapply power. Main body of code again appears to
> > run fine. I enter the command to test the Timer code and this time It
> > Works.
> >
> > The conclusion I draw is that "updated" MSP-FET430UIF JTAG port
> > used with the Elprotronics program is somehow interfering with the ACLK
> > reaching the timer. If I program the target and leave the JTAG cable
> > connected, the test routine fails. With the JTAG removed, the test
> > routine runs.
> >
> > The pins used by the JTAG are available as general port pins and are
> > assigned as inputs. There is a bit in the System Control Register (bit
> > 5 = SYSJTAGPIN, cleared after a BOR) that I have left in the Shared
> > (=0) state. I will try it again and see if the problem goes away when
> > setting it to Dedicated (=1)
> >
> > The code example was the last of a dozen variations I used trying to
> > find something that work. Hacked in the extreme. When something finally
> > worked, I left it as it was and moved on to what was different.
> >
> > Blakely
> >
> >
> > --- In m..., Onestone wrote:
> > >
> > > I don't know why thisa would be different in the two environments, but
> > > the method, as you describe it, fo initialisinging the timer is wrong.
> > >
> > > Code is essentially:
> > > 1) Initialize timer to reset conditions. i.e. Stopped/Cleared/Mode 0.
> > > 2) Initialize Capture Compare register 0 to 0x0000.
> > >
> > > At this point CCIFG in CCTLA0 will be set
> > >
> > > 3) Enable CCR0 interrupts.
> > >
> > > You have effectively enabled a CCRA0 interrupt on compare, the compare
> > value is 0, the count to value is 0, the counter behaviour is not to
> > run, probably, but to stall on 0 generating interrupts. There is also
> > likely to be an interrupt pending from POR
> > >
> > > 4) Set MC mode to count up to CCR0.
> > >
> > > You should have initialised the count to value first, before enabling
> > the timer or interrupts, then cleared the pending interrupt flag, before
> > enabling the interrupt
> > >
> > > 5) Load CCR0 interval, effectively starting counter.
> > >
> > > No, the counter starts when you clear the reset bit TACLR, whether
> > it's doing what you expect is a totally different thing
> > >
> > > 6) Drop port pin 3.0 low.
> > > 7) Wait for Interval complete.
> > > 8) Set port pin 3.0 high.
> > >
> > > You are enabling the interrupts before you have initialised their
> > values. The sequence I use is:-
> > >
> > > MOV #TICKRATE,&CCRA0 ;TIMER A 1 SECOND INTERRUPT
> > > MOV #MC_2+TASSEL_1+TACLR+ID_3,&TACTL;ACLK, CONTINUOUS MODE, OVF
> > DISABLED
> > > BIC #CCIFG,&CCTLA0 ;ENABLE TIMERA0 FOR 1 SECOND TICK
> > > BIS #CCIE,&CCTLA0 ;ENABLE TIMERA0 FOR 1 SECOND TICK
> > >
> > > Al
> > >
> > >
> > >
> > >
> > > On 14/05/2012 1:24 AM, Blakely wrote:
> > > > Progress: (Originally 5419A Timer problem and 8KB KickStart limit)
> > > >
> > > > 8K Kickstart limit: Resolved.
> > > > Timer problem: Unresolved.
> > > >
> > > > The timer problem is now driving me crazy.
> > > >
> > > > I have two programming environments that are closely related. Each
> > uses the KickStart for MSP430 Version 5.4 tools. One is entirely within
> > Kickstart, the other is outside of Kickstart.
> > > >
> > > > Environment 1: Kickstart
> > > > Assembler: a430.exe version 4.21.2 contained within KickStart.
> > > > Linker: xlink.exe version 4.6.10 contained within Kickstart.
> > > > Programmer: IAR CSpy debugger.
> > > > JTAG pod: MSP-FET430UIF running firmware version 2.04.01.004.
> > > >
> > > > In this environment, I can assemble the program and load it into my
> > target board via the JTAG port using the Debug and Download mode.
> > > > In debug, I release the program to run via "Go" and everything runs
> > fine. I can exit the debugger, remove the JTAG cable and re-power my
> > board and everything still runs as designed. I have a linker option
> > enabled to produce an extra output file in intel hex format.
> > > >
> > > > Environment 2: Discrete tools.
> > > > Assembler: a430.exe from KickStart above via command line.
> > > > Linker: xlink.exe from KickStart above via command line.
> > > > Programmer: Elprotronics FET-Pro430 Lite version 3.0-6.
> > > > JTAG pod: A different MSP-FET430UIF running firmware 3.02.03.015.
> > > >
> > > > In this environment, the program is executed via a Bat file and
> > produces an intel hex format file that is then loaded by the Elprotronic
> > programmer via the second "upgraded" FET430UIF into the target board.
> > This hex file is identical to the extra output file produced by
> > Environment #1.
> > > >
> > > > The only differences that I see are in the method of programming and
> > the JTAG pods.
> > > >
> > > > All previous code ran correctly until the Timer A0 routine was
> > added.
> > > > I have a short test routine accessed by command over the serial
> > port.
> > > > In the working version, pressing a key results in a 100 ms pulse on
> > an output pin. In the failing version, it appears that the Timer is
> > never being clocked. (ACLK from 32.768 KH XT1 source). ACLK is being
> > output on an ACLK port pin.
> > > >
> > > > Code is essentially:
> > > > 1) Initialize timer to reset conditions. i.e. Stopped/Cleared/Mode
> > 0.
> > > > 2) Initialize Capture Compare register 0 to 0x0000.
> > > > 3) Enable CCR0 interrupts.
> > > > 4) Set MC mode to count up to CCR0.
> > > > 5) Load CCR0 interval, effectively starting counter.
> > > > 6) Drop port pin 3.0 low.
> > > > 7) Wait for Interval complete.
> > > > 8) Set port pin 3.0 high.
> > > >
> > > > In the TA0 Source 0 ISR, we simply set a Flag detectable in the
> > > > foreground.
> > > >
> > > > Since the code runs in one environment but not in the other, I
> > assume that it is not the cause of the problem, but the target of some
> > other problem.
> > > >
> > > > CSpy is evidently adding something to the mix that I need to include
> > in my standalone environment.
> > > >
> > > > Any idea(s)?
> > > >
> > > > Blakely
> > > >
> > > >
> > > >
> > > >
> > > > --- In m..., "Blakely"blakely.lacroix@ wrote:
> > > >> I am bringing up a new design, based on the MSP430F5419A and have
> > run into an unusual problem.
> > > >>
> > > >> I have ported over a non interrupt driven timer wait routine that
> > uses TA0. It runs on a F148 part, but not on the 5419A. I have tried
> > it with both SMCLK and ACLK, both of which are output on port pins, so I
> > can see them running. Everything else runs just fine.
> > > >>
> > > >> It appears that the TA0 is not being clocked in that it never
> > increments and the value in CCR0 is never reached and CCIF is never set.
> > MC bits are non zero. Mode is 01 = Count up to CCR0 limit which should
> > set CCIF when reached.
> > > >>
> > > >> I did load a scaled back version using the IAR CSpy, and only once
> > did it run using ACLK. This makes me think that the stepping mode of
> > the debugger may be enabling something that is normally not enabled.
> > Any ideas? I don't have that much hair left to lose.
> > > >>
> > > >> Did anyone find a solution to the new 8K limit in the IAR
> > download/debug? Kind of silly to suddenly start limiting that. I did a
> > search for an earlier version of KickStart that perhaps did not have
> > that limitation. Anyone have a working version they can send me?
> > > >>
> > > >> Blakely
> > > >>
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Start a New Thread

I've never been able to reliably program the 5438A with just the UIF power supplied by the USB port. Seems the USB port does not provide enough to self power everything that uses the 3.3V on our target boards. There is strict timing related to the initial sequence to put the unit in JTAG mode instead of BSL (the Reset is part of the sequence). One of our boards had a 10uf cap across our manual reset button (for noise suppression) and it totally messed up our ability to reliably program the unit (and that board has the 1611 on it). One of the data sheets indicated that no more than a 10pf cap should be used along with the 47K pull-up (I suspect that most don't even need the cap). Once you have the chip in JTAG mode, a manual reset will take it out of the JTAG mode - I usually have to exit out of the programming / debugging tool, disconnect the pod from the USB port and then reconnect the pod and then restart the tool to get everything back to 'normal'.

----- Original Message -----
From: Blakely
To: m...
Sent: Sunday, May 13, 2012 3:45 PM
Subject: [msp430] Re: MSP430 F 5438A Timer / Environment issue. Very Weird.

We were running with the reset value of SYSJTAGPIN (=0). We then actively zeroed zero that bit as part of the bring up just to be sure. No change.

If we power the target board with the JTAG pod (Power in JTAG pin 2) and program the target using the Elprotronics programmer (EP), the unit fails until we toggle the power to the target. If we just issue a Reset (both of these activated by the EP buttons), we also fail.

We then added support to use the loss of Terminal DTR to invoke a Port 1.7 interrupt. The P1.7 ISR opens the PMMR, sets the PMMSWPOR closes the PMMR and does a RETI (just in case it actually take some time for the POR to be recognized. A Terminal Disconnect (Hangup) invokes the interrupt. Part is reset. Timer is still non operational.

If I program the part using the EP, leave the JTAG cable attached (Target power out JTAG pin 4) the Timer will fail. If I cycle the external power on the target board, the Timer works.

Basically, I need a complete removal of power from the board after programming with the EP to get the Timer to run. During all of these tests above, ACLK was still visible and active on a ACLK output pin.

From the evidence collected so far, I believe it has to do with the just the MSP-FET430UIF. The one used with the EP programmer was "updated" while the one used with the IAR debugger was the standard issue. Unfortunatly, the standard issue is no longer standard in that we did have the option under IAR (exercised) to do an update as well.

Since I actually have to produce something and do have a workaround (repower the target board), I will move on. I hate fighting with the tools. This reduces confidence overall. There are enough potential gotchas out there. Tools should not be one of them.

This post can serve as a searchable marker for other who might run into this problem. But something is not quite right with the EP and the JTAG port. I will double check the TI errata on this. Maybe it is a new event.

Thanks to Steve and Al for support on Mother's Day.

Blakely

--- In m..., "Steve Mayfield" wrote:
>
> Putting the JTAG pins in dedicated mode (SYSJTAGPIN=1) will cause problems with some programming tools that expect the target to have shared pins. I found this out with the REP430 (Replicator). If the JTAG pins are in the dedicated mode, the JTAG sequence used to retrieve the CoreId does not work. Normally the I/O pins are switched to JTAG mode using the TEST signal. I had to chage the sequence to retrieve the CoreId first with the TEST signal high and if that failed to drop the TEST signal and try again. The TEST signal was not used in the 1xx series, but is required for the 5xx series with shared I/O pins.
>
>
> ----- Original Message -----
> From: Blakely
> To: m...
> Sent: Sunday, May 13, 2012 11:52 AM
> Subject: [msp430] Re: MSP430 F 5438A Timer / Environment issue. Very Weird.
>
>
>
> I now have Al's code in place. Same result.
> Makes no difference if we select Timer A0 or Timer A1 or use ACLK or SMCLK. If the JTAG cable is in place after a reset, the Timers do not run. This appears to be true even after I exit the Elprotronics program. Remove the JTAG cable, PUC the device and they run.
>
> I will double check my hardware connections and add another source of reset - DTR on a Port 1 pin and see if it is related to PUC or other.
>
> The mystery continues.
>
> Blakely
>
> --- In m..., "Blakely" wrote:
> >
> > Al
> >
> > Thanks for the quick response! You are a great resource.
> >
> > I have some more information that is independent of the code issues.
> >
> > First I used the Elprotronics programmer to pull back the code images of
> > the working code and the non working code. These come back as text
> > files and so they are easy to check against each other. They Match!
> > Now the last remaining hairs from my head are gone. Crazy.
> >
> > It gets better: I used the failing environment to program the target
> > board. Main body of code appears to run fine. I enter the command to
> > test the Timer code and as expected, it fails. I removed the JTAG
> > cable, remove power, reapply power. Main body of code again appears to
> > run fine. I enter the command to test the Timer code and this time It
> > Works.
> >
> > The conclusion I draw is that "updated" MSP-FET430UIF JTAG port
> > used with the Elprotronics program is somehow interfering with the ACLK
> > reaching the timer. If I program the target and leave the JTAG cable
> > connected, the test routine fails. With the JTAG removed, the test
> > routine runs.
> >
> > The pins used by the JTAG are available as general port pins and are
> > assigned as inputs. There is a bit in the System Control Register (bit
> > 5 = SYSJTAGPIN, cleared after a BOR) that I have left in the Shared
> > (=0) state. I will try it again and see if the problem goes away when
> > setting it to Dedicated (=1)
> >
> > The code example was the last of a dozen variations I used trying to
> > find something that work. Hacked in the extreme. When something finally
> > worked, I left it as it was and moved on to what was different.
> >
> > Blakely
> >
> >
> > --- In m..., Onestone wrote:
> > >
> > > I don't know why thisa would be different in the two environments, but
> > > the method, as you describe it, fo initialisinging the timer is wrong.
> > >
> > > Code is essentially:
> > > 1) Initialize timer to reset conditions. i.e. Stopped/Cleared/Mode 0.
> > > 2) Initialize Capture Compare register 0 to 0x0000.
> > >
> > > At this point CCIFG in CCTLA0 will be set
> > >
> > > 3) Enable CCR0 interrupts.
> > >
> > > You have effectively enabled a CCRA0 interrupt on compare, the compare
> > value is 0, the count to value is 0, the counter behaviour is not to
> > run, probably, but to stall on 0 generating interrupts. There is also
> > likely to be an interrupt pending from POR
> > >
> > > 4) Set MC mode to count up to CCR0.
> > >
> > > You should have initialised the count to value first, before enabling
> > the timer or interrupts, then cleared the pending interrupt flag, before
> > enabling the interrupt
> > >
> > > 5) Load CCR0 interval, effectively starting counter.
> > >
> > > No, the counter starts when you clear the reset bit TACLR, whether
> > it's doing what you expect is a totally different thing
> > >
> > > 6) Drop port pin 3.0 low.
> > > 7) Wait for Interval complete.
> > > 8) Set port pin 3.0 high.
> > >
> > > You are enabling the interrupts before you have initialised their
> > values. The sequence I use is:-
> > >
> > > MOV #TICKRATE,&CCRA0 ;TIMER A 1 SECOND INTERRUPT
> > > MOV #MC_2+TASSEL_1+TACLR+ID_3,&TACTL;ACLK, CONTINUOUS MODE, OVF
> > DISABLED
> > > BIC #CCIFG,&CCTLA0 ;ENABLE TIMERA0 FOR 1 SECOND TICK
> > > BIS #CCIE,&CCTLA0 ;ENABLE TIMERA0 FOR 1 SECOND TICK
> > >
> > > Al
> > >
> > >
> > >
> > >
> > > On 14/05/2012 1:24 AM, Blakely wrote:
> > > > Progress: (Originally 5419A Timer problem and 8KB KickStart limit)
> > > >
> > > > 8K Kickstart limit: Resolved.
> > > > Timer problem: Unresolved.
> > > >
> > > > The timer problem is now driving me crazy.
> > > >
> > > > I have two programming environments that are closely related. Each
> > uses the KickStart for MSP430 Version 5.4 tools. One is entirely within
> > Kickstart, the other is outside of Kickstart.
> > > >
> > > > Environment 1: Kickstart
> > > > Assembler: a430.exe version 4.21.2 contained within KickStart.
> > > > Linker: xlink.exe version 4.6.10 contained within Kickstart.
> > > > Programmer: IAR CSpy debugger.
> > > > JTAG pod: MSP-FET430UIF running firmware version 2.04.01.004.
> > > >
> > > > In this environment, I can assemble the program and load it into my
> > target board via the JTAG port using the Debug and Download mode.
> > > > In debug, I release the program to run via "Go" and everything runs
> > fine. I can exit the debugger, remove the JTAG cable and re-power my
> > board and everything still runs as designed. I have a linker option
> > enabled to produce an extra output file in intel hex format.
> > > >
> > > > Environment 2: Discrete tools.
> > > > Assembler: a430.exe from KickStart above via command line.
> > > > Linker: xlink.exe from KickStart above via command line.
> > > > Programmer: Elprotronics FET-Pro430 Lite version 3.0-6.
> > > > JTAG pod: A different MSP-FET430UIF running firmware 3.02.03.015.
> > > >
> > > > In this environment, the program is executed via a Bat file and
> > produces an intel hex format file that is then loaded by the Elprotronic
> > programmer via the second "upgraded" FET430UIF into the target board.
> > This hex file is identical to the extra output file produced by
> > Environment #1.
> > > >
> > > > The only differences that I see are in the method of programming and
> > the JTAG pods.
> > > >
> > > > All previous code ran correctly until the Timer A0 routine was
> > added.
> > > > I have a short test routine accessed by command over the serial
> > port.
> > > > In the working version, pressing a key results in a 100 ms pulse on
> > an output pin. In the failing version, it appears that the Timer is
> > never being clocked. (ACLK from 32.768 KH XT1 source). ACLK is being
> > output on an ACLK port pin.
> > > >
> > > > Code is essentially:
> > > > 1) Initialize timer to reset conditions. i.e. Stopped/Cleared/Mode
> > 0.
> > > > 2) Initialize Capture Compare register 0 to 0x0000.
> > > > 3) Enable CCR0 interrupts.
> > > > 4) Set MC mode to count up to CCR0.
> > > > 5) Load CCR0 interval, effectively starting counter.
> > > > 6) Drop port pin 3.0 low.
> > > > 7) Wait for Interval complete.
> > > > 8) Set port pin 3.0 high.
> > > >
> > > > In the TA0 Source 0 ISR, we simply set a Flag detectable in the
> > > > foreground.
> > > >
> > > > Since the code runs in one environment but not in the other, I
> > assume that it is not the cause of the problem, but the target of some
> > other problem.
> > > >
> > > > CSpy is evidently adding something to the mix that I need to include
> > in my standalone environment.
> > > >
> > > > Any idea(s)?
> > > >
> > > > Blakely
> > > >
> > > >
> > > >
> > > >
> > > > --- In m..., "Blakely"blakely.lacroix@ wrote:
> > > >> I am bringing up a new design, based on the MSP430F5419A and have
> > run into an unusual problem.
> > > >>
> > > >> I have ported over a non interrupt driven timer wait routine that
> > uses TA0. It runs on a F148 part, but not on the 5419A. I have tried
> > it with both SMCLK and ACLK, both of which are output on port pins, so I
> > can see them running. Everything else runs just fine.
> > > >>
> > > >> It appears that the TA0 is not being clocked in that it never
> > increments and the value in CCR0 is never reached and CCIF is never set.
> > MC bits are non zero. Mode is 01 = Count up to CCR0 limit which should
> > set CCIF when reached.
> > > >>
> > > >> I did load a scaled back version using the IAR CSpy, and only once
> > did it run using ACLK. This makes me think that the stepping mode of
> > the debugger may be enabling something that is normally not enabled.
> > Any ideas? I don't have that much hair left to lose.
> > > >>
> > > >> Did anyone find a solution to the new 8K limit in the IAR
> > download/debug? Kind of silly to suddenly start limiting that. I did a
> > search for an earlier version of KickStart that perhaps did not have
> > that limitation. Anyone have a working version they can send me?
> > > >>
> > > >> Blakely
> > > >>
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Start a New Thread

Hi Blakely, my only thought on the difference between programmers would
be perhaps clock or power supply loading. I have had instances where a
program will run on the programming tool, but not on stand alone at
first. This was traced back to the clock not stabilising fully, and the
NMI not being handled. (final code does this, but not always test code
as it can mask some bugs). Basically in this case the clock destabilised
under load, due to a bouncing on switch, the clock fault triggered, and
locked me out. On other occasions I found that i couldn't run cleanly
when powering from the FET programmer, but haven't had that problem for
a while. I have never used programmers other than the FET tool and the
USB dongle.

Cheers

AL

On 14/05/2012 2:39 AM, Blakely wrote:
> Al
>
> Thanks for the quick response! You are a great resource.
>
> I have some more information that is independent of the code issues.
>
> First I used the Elprotronics programmer to pull back the code images of
> the working code and the non working code. These come back as text
> files and so they are easy to check against each other. They Match!
> Now the last remaining hairs from my head are gone. Crazy.
>
> It gets better: I used the failing environment to program the target
> board. Main body of code appears to run fine. I enter the command to
> test the Timer code and as expected, it fails. I removed the JTAG
> cable, remove power, reapply power. Main body of code again appears to
> run fine. I enter the command to test the Timer code and this time It
> Works.
>
> The conclusion I draw is that "updated" MSP-FET430UIF JTAG port
> used with the Elprotronics program is somehow interfering with the ACLK
> reaching the timer. If I program the target and leave the JTAG cable
> connected, the test routine fails. With the JTAG removed, the test
> routine runs.
>
> The pins used by the JTAG are available as general port pins and are
> assigned as inputs. There is a bit in the System Control Register (bit
> 5 = SYSJTAGPIN, cleared after a BOR) that I have left in the Shared
> (=0) state. I will try it again and see if the problem goes away when
> setting it to Dedicated (=1)
>
> The code example was the last of a dozen variations I used trying to
> find something that work. Hacked in the extreme. When something finally
> worked, I left it as it was and moved on to what was different.
>
> Blakely
> --- In m..., Onestone wrote:
>> I don't know why thisa would be different in the two environments, but
>> the method, as you describe it, fo initialisinging the timer is wrong.
>>
>> Code is essentially:
>> 1) Initialize timer to reset conditions. i.e. Stopped/Cleared/Mode 0.
>> 2) Initialize Capture Compare register 0 to 0x0000.
>>
>> At this point CCIFG in CCTLA0 will be set
>>
>> 3) Enable CCR0 interrupts.
>>
>> You have effectively enabled a CCRA0 interrupt on compare, the compare
> value is 0, the count to value is 0, the counter behaviour is not to
> run, probably, but to stall on 0 generating interrupts. There is also
> likely to be an interrupt pending from POR
>> 4) Set MC mode to count up to CCR0.
>>
>> You should have initialised the count to value first, before enabling
> the timer or interrupts, then cleared the pending interrupt flag, before
> enabling the interrupt
>> 5) Load CCR0 interval, effectively starting counter.
>>
>> No, the counter starts when you clear the reset bit TACLR, whether
> it's doing what you expect is a totally different thing
>> 6) Drop port pin 3.0 low.
>> 7) Wait for Interval complete.
>> 8) Set port pin 3.0 high.
>>
>> You are enabling the interrupts before you have initialised their
> values. The sequence I use is:-
>> MOV #TICKRATE,&CCRA0 ;TIMER A 1 SECOND INTERRUPT
>> MOV #MC_2+TASSEL_1+TACLR+ID_3,&TACTL;ACLK, CONTINUOUS MODE, OVF
> DISABLED
>> BIC #CCIFG,&CCTLA0 ;ENABLE TIMERA0 FOR 1 SECOND TICK
>> BIS #CCIE,&CCTLA0 ;ENABLE TIMERA0 FOR 1 SECOND TICK
>>
>> Al
>> On 14/05/2012 1:24 AM, Blakely wrote:
>>> Progress: (Originally 5419A Timer problem and 8KB KickStart limit)
>>>
>>> 8K Kickstart limit: Resolved.
>>> Timer problem: Unresolved.
>>>
>>> The timer problem is now driving me crazy.
>>>
>>> I have two programming environments that are closely related. Each
> uses the KickStart for MSP430 Version 5.4 tools. One is entirely within
> Kickstart, the other is outside of Kickstart.
>>> Environment 1: Kickstart
>>> Assembler: a430.exe version 4.21.2 contained within KickStart.
>>> Linker: xlink.exe version 4.6.10 contained within Kickstart.
>>> Programmer: IAR CSpy debugger.
>>> JTAG pod: MSP-FET430UIF running firmware version 2.04.01.004.
>>>
>>> In this environment, I can assemble the program and load it into my
> target board via the JTAG port using the Debug and Download mode.
>>> In debug, I release the program to run via "Go" and everything runs
> fine. I can exit the debugger, remove the JTAG cable and re-power my
> board and everything still runs as designed. I have a linker option
> enabled to produce an extra output file in intel hex format.
>>> Environment 2: Discrete tools.
>>> Assembler: a430.exe from KickStart above via command line.
>>> Linker: xlink.exe from KickStart above via command line.
>>> Programmer: Elprotronics FET-Pro430 Lite version 3.0-6.
>>> JTAG pod: A different MSP-FET430UIF running firmware 3.02.03.015.
>>>
>>> In this environment, the program is executed via a Bat file and
> produces an intel hex format file that is then loaded by the Elprotronic
> programmer via the second "upgraded" FET430UIF into the target board.
> This hex file is identical to the extra output file produced by
> Environment #1.
>>> The only differences that I see are in the method of programming and
> the JTAG pods.
>>> All previous code ran correctly until the Timer A0 routine was
> added.
>>> I have a short test routine accessed by command over the serial
> port.
>>> In the working version, pressing a key results in a 100 ms pulse on
> an output pin. In the failing version, it appears that the Timer is
> never being clocked. (ACLK from 32.768 KH XT1 source). ACLK is being
> output on an ACLK port pin.
>>> Code is essentially:
>>> 1) Initialize timer to reset conditions. i.e. Stopped/Cleared/Mode
> 0.
>>> 2) Initialize Capture Compare register 0 to 0x0000.
>>> 3) Enable CCR0 interrupts.
>>> 4) Set MC mode to count up to CCR0.
>>> 5) Load CCR0 interval, effectively starting counter.
>>> 6) Drop port pin 3.0 low.
>>> 7) Wait for Interval complete.
>>> 8) Set port pin 3.0 high.
>>>
>>> In the TA0 Source 0 ISR, we simply set a Flag detectable in the
>>> foreground.
>>>
>>> Since the code runs in one environment but not in the other, I
> assume that it is not the cause of the problem, but the target of some
> other problem.
>>> CSpy is evidently adding something to the mix that I need to include
> in my standalone environment.
>>> Any idea(s)?
>>>
>>> Blakely
>>>
>>>
>>>
>>>
>>> --- In m..., "Blakely"blakely.lacroix@ wrote:
>>>> I am bringing up a new design, based on the MSP430F5419A and have
> run into an unusual problem.
>>>> I have ported over a non interrupt driven timer wait routine that
> uses TA0. It runs on a F148 part, but not on the 5419A. I have tried
> it with both SMCLK and ACLK, both of which are output on port pins, so I
> can see them running. Everything else runs just fine.
>>>> It appears that the TA0 is not being clocked in that it never
> increments and the value in CCR0 is never reached and CCIF is never set.
> MC bits are non zero. Mode is 01 = Count up to CCR0 limit which should
> set CCIF when reached.
>>>> I did load a scaled back version using the IAR CSpy, and only once
> did it run using ACLK. This makes me think that the stepping mode of
> the debugger may be enabling something that is normally not enabled.
> Any ideas? I don't have that much hair left to lose.
>>>> Did anyone find a solution to the new 8K limit in the IAR
> download/debug? Kind of silly to suddenly start limiting that. I did a
> search for an earlier version of KickStart that perhaps did not have
> that limitation. Anyone have a working version they can send me?
>>>> Blakely
>>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Start a New Thread

We do have a small cap across the RST line, per the 5419A/5438A data sheet.

What really drives me crazy in this is that all the code works except the Timer A0 and Timer A1 routines. There is just no Clock being delivered to the timers, be it ACLK or SMCLK, or the timers are in a permanent clear state.

Just plain weird.

Blakely

--- In m..., "Steve Mayfield" wrote:
>
> I've never been able to reliably program the 5438A with just the UIF power supplied by the USB port. Seems the USB port does not provide enough to self power everything that uses the 3.3V on our target boards. There is strict timing related to the initial sequence to put the unit in JTAG mode instead of BSL (the Reset is part of the sequence). One of our boards had a 10uf cap across our manual reset button (for noise suppression) and it totally messed up our ability to reliably program the unit (and that board has the 1611 on it). One of the data sheets indicated that no more than a 10pf cap should be used along with the 47K pull-up (I suspect that most don't even need the cap). Once you have the chip in JTAG mode, a manual reset will take it out of the JTAG mode - I usually have to exit out of the programming / debugging tool, disconnect the pod from the USB port and then reconnect the pod and then restart the tool to get everything back to 'normal'.
>
> ----- Original Message -----
> From: Blakely
> To: m...
> Sent: Sunday, May 13, 2012 3:45 PM
> Subject: [msp430] Re: MSP430 F 5438A Timer / Environment issue. Very Weird.
>
> We were running with the reset value of SYSJTAGPIN (=0). We then actively zeroed zero that bit as part of the bring up just to be sure. No change.
>
> If we power the target board with the JTAG pod (Power in JTAG pin 2) and program the target using the Elprotronics programmer (EP), the unit fails until we toggle the power to the target. If we just issue a Reset (both of these activated by the EP buttons), we also fail.
>
> We then added support to use the loss of Terminal DTR to invoke a Port 1.7 interrupt. The P1.7 ISR opens the PMMR, sets the PMMSWPOR closes the PMMR and does a RETI (just in case it actually take some time for the POR to be recognized. A Terminal Disconnect (Hangup) invokes the interrupt. Part is reset. Timer is still non operational.
>
> If I program the part using the EP, leave the JTAG cable attached (Target power out JTAG pin 4) the Timer will fail. If I cycle the external power on the target board, the Timer works.
>
> Basically, I need a complete removal of power from the board after programming with the EP to get the Timer to run. During all of these tests above, ACLK was still visible and active on a ACLK output pin.
>
> From the evidence collected so far, I believe it has to do with the just the MSP-FET430UIF. The one used with the EP programmer was "updated" while the one used with the IAR debugger was the standard issue. Unfortunatly, the standard issue is no longer standard in that we did have the option under IAR (exercised) to do an update as well.
>
> Since I actually have to produce something and do have a workaround (repower the target board), I will move on. I hate fighting with the tools. This reduces confidence overall. There are enough potential gotchas out there. Tools should not be one of them.
>
> This post can serve as a searchable marker for other who might run into this problem. But something is not quite right with the EP and the JTAG port. I will double check the TI errata on this. Maybe it is a new event.
>
> Thanks to Steve and Al for support on Mother's Day.
>
> Blakely
>
> --- In m..., "Steve Mayfield" wrote:
> >
> > Putting the JTAG pins in dedicated mode (SYSJTAGPIN=1) will cause problems with some programming tools that expect the target to have shared pins. I found this out with the REP430 (Replicator). If the JTAG pins are in the dedicated mode, the JTAG sequence used to retrieve the CoreId does not work. Normally the I/O pins are switched to JTAG mode using the TEST signal. I had to chage the sequence to retrieve the CoreId first with the TEST signal high and if that failed to drop the TEST signal and try again. The TEST signal was not used in the 1xx series, but is required for the 5xx series with shared I/O pins.
> >
> >
> > ----- Original Message -----
> > From: Blakely
> > To: m...
> > Sent: Sunday, May 13, 2012 11:52 AM
> > Subject: [msp430] Re: MSP430 F 5438A Timer / Environment issue. Very Weird.
> >
> >
> >
> > I now have Al's code in place. Same result.
> > Makes no difference if we select Timer A0 or Timer A1 or use ACLK or SMCLK. If the JTAG cable is in place after a reset, the Timers do not run. This appears to be true even after I exit the Elprotronics program. Remove the JTAG cable, PUC the device and they run.
> >
> > I will double check my hardware connections and add another source of reset - DTR on a Port 1 pin and see if it is related to PUC or other.
> >
> > The mystery continues.
> >
> > Blakely
> >
> > --- In m..., "Blakely" wrote:
> > >
> > > Al
> > >
> > > Thanks for the quick response! You are a great resource.
> > >
> > > I have some more information that is independent of the code issues.
> > >
> > > First I used the Elprotronics programmer to pull back the code images of
> > > the working code and the non working code. These come back as text
> > > files and so they are easy to check against each other. They Match!
> > > Now the last remaining hairs from my head are gone. Crazy.
> > >
> > > It gets better: I used the failing environment to program the target
> > > board. Main body of code appears to run fine. I enter the command to
> > > test the Timer code and as expected, it fails. I removed the JTAG
> > > cable, remove power, reapply power. Main body of code again appears to
> > > run fine. I enter the command to test the Timer code and this time It
> > > Works.
> > >
> > > The conclusion I draw is that "updated" MSP-FET430UIF JTAG port
> > > used with the Elprotronics program is somehow interfering with the ACLK
> > > reaching the timer. If I program the target and leave the JTAG cable
> > > connected, the test routine fails. With the JTAG removed, the test
> > > routine runs.
> > >
> > > The pins used by the JTAG are available as general port pins and are
> > > assigned as inputs. There is a bit in the System Control Register (bit
> > > 5 = SYSJTAGPIN, cleared after a BOR) that I have left in the Shared
> > > (=0) state. I will try it again and see if the problem goes away when
> > > setting it to Dedicated (=1)
> > >
> > > The code example was the last of a dozen variations I used trying to
> > > find something that work. Hacked in the extreme. When something finally
> > > worked, I left it as it was and moved on to what was different.
> > >
> > > Blakely
> > >
> > >
> > > --- In m..., Onestone wrote:
> > > >
> > > > I don't know why thisa would be different in the two environments, but
> > > > the method, as you describe it, fo initialisinging the timer is wrong.
> > > >
> > > > Code is essentially:
> > > > 1) Initialize timer to reset conditions. i.e. Stopped/Cleared/Mode 0.
> > > > 2) Initialize Capture Compare register 0 to 0x0000.
> > > >
> > > > At this point CCIFG in CCTLA0 will be set
> > > >
> > > > 3) Enable CCR0 interrupts.
> > > >
> > > > You have effectively enabled a CCRA0 interrupt on compare, the compare
> > > value is 0, the count to value is 0, the counter behaviour is not to
> > > run, probably, but to stall on 0 generating interrupts. There is also
> > > likely to be an interrupt pending from POR
> > > >
> > > > 4) Set MC mode to count up to CCR0.
> > > >
> > > > You should have initialised the count to value first, before enabling
> > > the timer or interrupts, then cleared the pending interrupt flag, before
> > > enabling the interrupt
> > > >
> > > > 5) Load CCR0 interval, effectively starting counter.
> > > >
> > > > No, the counter starts when you clear the reset bit TACLR, whether
> > > it's doing what you expect is a totally different thing
> > > >
> > > > 6) Drop port pin 3.0 low.
> > > > 7) Wait for Interval complete.
> > > > 8) Set port pin 3.0 high.
> > > >
> > > > You are enabling the interrupts before you have initialised their
> > > values. The sequence I use is:-
> > > >
> > > > MOV #TICKRATE,&CCRA0 ;TIMER A 1 SECOND INTERRUPT
> > > > MOV #MC_2+TASSEL_1+TACLR+ID_3,&TACTL;ACLK, CONTINUOUS MODE, OVF
> > > DISABLED
> > > > BIC #CCIFG,&CCTLA0 ;ENABLE TIMERA0 FOR 1 SECOND TICK
> > > > BIS #CCIE,&CCTLA0 ;ENABLE TIMERA0 FOR 1 SECOND TICK
> > > >
> > > > Al
> > > >
> > > >
> > > >
> > > >
> > > > On 14/05/2012 1:24 AM, Blakely wrote:
> > > > > Progress: (Originally 5419A Timer problem and 8KB KickStart limit)
> > > > >
> > > > > 8K Kickstart limit: Resolved.
> > > > > Timer problem: Unresolved.
> > > > >
> > > > > The timer problem is now driving me crazy.
> > > > >
> > > > > I have two programming environments that are closely related. Each
> > > uses the KickStart for MSP430 Version 5.4 tools. One is entirely within
> > > Kickstart, the other is outside of Kickstart.
> > > > >
> > > > > Environment 1: Kickstart
> > > > > Assembler: a430.exe version 4.21.2 contained within KickStart.
> > > > > Linker: xlink.exe version 4.6.10 contained within Kickstart.
> > > > > Programmer: IAR CSpy debugger.
> > > > > JTAG pod: MSP-FET430UIF running firmware version 2.04.01.004.
> > > > >
> > > > > In this environment, I can assemble the program and load it into my
> > > target board via the JTAG port using the Debug and Download mode.
> > > > > In debug, I release the program to run via "Go" and everything runs
> > > fine. I can exit the debugger, remove the JTAG cable and re-power my
> > > board and everything still runs as designed. I have a linker option
> > > enabled to produce an extra output file in intel hex format.
> > > > >
> > > > > Environment 2: Discrete tools.
> > > > > Assembler: a430.exe from KickStart above via command line.
> > > > > Linker: xlink.exe from KickStart above via command line.
> > > > > Programmer: Elprotronics FET-Pro430 Lite version 3.0-6.
> > > > > JTAG pod: A different MSP-FET430UIF running firmware 3.02.03.015.
> > > > >
> > > > > In this environment, the program is executed via a Bat file and
> > > produces an intel hex format file that is then loaded by the Elprotronic
> > > programmer via the second "upgraded" FET430UIF into the target board.
> > > This hex file is identical to the extra output file produced by
> > > Environment #1.
> > > > >
> > > > > The only differences that I see are in the method of programming and
> > > the JTAG pods.
> > > > >
> > > > > All previous code ran correctly until the Timer A0 routine was
> > > added.
> > > > > I have a short test routine accessed by command over the serial
> > > port.
> > > > > In the working version, pressing a key results in a 100 ms pulse on
> > > an output pin. In the failing version, it appears that the Timer is
> > > never being clocked. (ACLK from 32.768 KH XT1 source). ACLK is being
> > > output on an ACLK port pin.
> > > > >
> > > > > Code is essentially:
> > > > > 1) Initialize timer to reset conditions. i.e. Stopped/Cleared/Mode
> > > 0.
> > > > > 2) Initialize Capture Compare register 0 to 0x0000.
> > > > > 3) Enable CCR0 interrupts.
> > > > > 4) Set MC mode to count up to CCR0.
> > > > > 5) Load CCR0 interval, effectively starting counter.
> > > > > 6) Drop port pin 3.0 low.
> > > > > 7) Wait for Interval complete.
> > > > > 8) Set port pin 3.0 high.
> > > > >
> > > > > In the TA0 Source 0 ISR, we simply set a Flag detectable in the
> > > > > foreground.
> > > > >
> > > > > Since the code runs in one environment but not in the other, I
> > > assume that it is not the cause of the problem, but the target of some
> > > other problem.
> > > > >
> > > > > CSpy is evidently adding something to the mix that I need to include
> > > in my standalone environment.
> > > > >
> > > > > Any idea(s)?
> > > > >
> > > > > Blakely
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > --- In m..., "Blakely"blakely.lacroix@ wrote:
> > > > >> I am bringing up a new design, based on the MSP430F5419A and have
> > > run into an unusual problem.
> > > > >>
> > > > >> I have ported over a non interrupt driven timer wait routine that
> > > uses TA0. It runs on a F148 part, but not on the 5419A. I have tried
> > > it with both SMCLK and ACLK, both of which are output on port pins, so I
> > > can see them running. Everything else runs just fine.
> > > > >>
> > > > >> It appears that the TA0 is not being clocked in that it never
> > > increments and the value in CCR0 is never reached and CCIF is never set.
> > > MC bits are non zero. Mode is 01 = Count up to CCR0 limit which should
> > > set CCIF when reached.
> > > > >>
> > > > >> I did load a scaled back version using the IAR CSpy, and only once
> > > did it run using ACLK. This makes me think that the stepping mode of
> > > the debugger may be enabling something that is normally not enabled.
> > > Any ideas? I don't have that much hair left to lose.
> > > > >>
> > > > >> Did anyone find a solution to the new 8K limit in the IAR
> > > download/debug? Kind of silly to suddenly start limiting that. I did a
> > > search for an earlier version of KickStart that perhaps did not have
> > > that limitation. Anyone have a working version they can send me?
> > > > >>
> > > > >> Blakely
> > > > >>
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Start a New Thread