OK, I am having some more problems with mspgcc. I have the following code (changed headers) from TI's slac080e timer_a interrupt demo. It's supposed to set up a timer A interrupt to toggle an LED.

//--------code-----------
#include
#include

void main(void)
{
WDTCTL = WDTPW + WDTHOLD; // Stop WDT
P1DIR |= 0x01; // P1.0 output
CCTL0 = CCIE; // CCR0 interrupt enabled
CCR0 = 50000;
TACTL = TASSEL_2 + MC_2; // SMCLK, contmode

_BIS_SR(LPM0_bits + GIE); // Enter LPM0 w/ interrupt
}

// Timer A0 interrupt service routine
#pragma vector=TIMERA0_VECTOR
__interrupt void Timer_A (void)
{
P1OUT ^= 0x01; // Toggle P1.0
CCR0 += 50000; // Add Offset to CCR0
}
//--------end code ---------

So, with mspgcc the code works as expected, right out of the box toggling an led on P1.0. The problem is changing the CCR0 += 50000 to a larger or smaller value has no effect on the LED timing. I feel like it's not really interrupting, and I'm seeing some other effect instead (running all the way through program memory and looping back???).

I have already tried changing to the standard mspgcc interrupt routine call ( interrupt(TIMERA0_VECTOR) Timer_A (void) ), but nothing changed. I've also tried putting a while(1) loop in main to ensure the cpu execution stays trapped there. I've struggled with variations of this code for hours without making any progress. Any ideas?

-Thanks!
------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

Can you show us what assembly or machine code mspgcc generates? It should not be much more than 100 bytes. A hex memory dump of the lowest address part of the Flash will do.

Also what are at 0xFFF2-3 and 0xFFFE-F?

--- In m...@yahoogroups.com, "charper_99" wrote:
>
> OK, I am having some more problems with mspgcc. I have the following code (changed headers) from TI's slac080e timer_a interrupt demo. It's supposed to set up a timer A interrupt to toggle an LED.
>
> //--------code-----------
> #include
> #include void main(void)
> {
> WDTCTL = WDTPW + WDTHOLD; // Stop WDT
> P1DIR |= 0x01; // P1.0 output
> CCTL0 = CCIE; // CCR0 interrupt enabled
> CCR0 = 50000;
> TACTL = TASSEL_2 + MC_2; // SMCLK, contmode
>
> _BIS_SR(LPM0_bits + GIE); // Enter LPM0 w/ interrupt
> }
>
> // Timer A0 interrupt service routine
> #pragma vector=TIMERA0_VECTOR
> __interrupt void Timer_A (void)
> {
> P1OUT ^= 0x01; // Toggle P1.0
> CCR0 += 50000; // Add Offset to CCR0
> }
> //--------end code ---------
>
> So, with mspgcc the code works as expected, right out of the box toggling an led on P1.0. The problem is changing the CCR0 += 50000 to a larger or smaller value has no effect on the LED timing. I feel like it's not really interrupting, and I'm seeing some other effect instead (running all the way through program memory and looping back???).
>
> I have already tried changing to the standard mspgcc interrupt routine call ( interrupt(TIMERA0_VECTOR) Timer_A (void) ), but nothing changed. I've also tried putting a while(1) loop in main to ensure the cpu execution stays trapped there. I've struggled with variations of this code for hours without making any progress. Any ideas?
>
> -Thanks!
>
------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

--- In m...@yahoogroups.com, "old_cow_yellow" wrote:
>
> Can you show us what assembly or machine code mspgcc generates? It should not be much more than 100 bytes. A hex memory dump of the lowest address part of the Flash will do.
>
> Also what are at 0xFFF2-3 and 0xFFFE-F?

Thanks for the quick response.
Unfortunately, I don't think it's possible to generate a nice human-readable opcode output. Unless I'm missing something, there's nothing as high up as 0xFFF23 Here's the entire hex dump:

:10F8000031408002B240805A20013F4000000F93F7
:10F8100005242F839F4F7CF80002FB233F4000000C
:10F820000F9304241F83CF430002FC23304036F89B
:10F83000304034F80013314080020441B240805A15
:10F840002001D2D32200B24010006201B24050C366
:10F850007201B2402002600132D0180030407AF8C4
:10F860000F1205120412D2E321003F4050C3825F01
:0CF870007201344135413F410013FF3F5D
:10FFE00030F830F830F830F830F830F830F830F8D1
:10FFF00030F860F830F830F830F830F830F800F8C1
:040000030000F80001
:00000001FF
------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

The code seems okay. The LED should blink ~10 times per second. If you change the +=50000 to +=5000, it should blink ~100 times per second. Can you tell the difference?

If you change it to too small a number, you will be back to ~10 times per second. May be that is what confused you.

--- In m...@yahoogroups.com, "charper_99" wrote:
>
> --- In m...@yahoogroups.com, "old_cow_yellow" wrote:
> >
> > Can you show us what assembly or machine code mspgcc generates? It should not be much more than 100 bytes. A hex memory dump of the lowest address part of the Flash will do.
> >
> > Also what are at 0xFFF2-3 and 0xFFFE-F?
>
> Thanks for the quick response.
> Unfortunately, I don't think it's possible to generate a nice human-readable opcode output. Unless I'm missing something, there's nothing as high up as 0xFFF23 Here's the entire hex dump:
>
> :10F8000031408002B240805A20013F4000000F93F7
> :10F8100005242F839F4F7CF80002FB233F4000000C
> :10F820000F9304241F83CF430002FC23304036F89B
> :10F83000304034F80013314080020441B240805A15
> :10F840002001D2D32200B24010006201B24050C366
> :10F850007201B2402002600132D0180030407AF8C4
> :10F860000F1205120412D2E321003F4050C3825F01
> :0CF870007201344135413F410013FF3F5D
> :10FFE00030F830F830F830F830F830F830F830F8D1
> :10FFF00030F860F830F830F830F830F830F800F8C1
> :040000030000F80001
> :00000001FF
>
------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

BTW, here is the code:

ORG 0xF800
c_start:
mov.w #0x280,SP
mov.w #0x5A80,&WDTCTL
mov.w #0x0,R15
tst.w R15
jeq done_that

copy_const:
decd.w R15
mov.w 0xF87C(R15),0x200(R15)
jne copy_const

done_that:
mov.w #0x0,R15
tst.w R15
jeq been_there

copy_zero:
dec.w R15
clr.b 0x200(R15)
jne copy_zero

been_there:
br #start

other_ISR:
br #0xF834
reti

start:
mov.w #0x280,SP
mov.w SP,R4

main:
mov.w #0x5A80,&WDTCTL
bis.b #0x1,&P1DIR
mov.w #0x10,&TACCTL0
mov.w #0xC350,&TACCR0
mov.w #0x220,&TACTL
bis.w #0x18,SR
br #c_exit

TA0_ISR:
push.w R15
push.w R5
push.w R4
xor.b #0x1,&P1OUT
mov.w #0xC350,R15
add.w R15,&TACCR0
pop.w R4
pop.w R5
pop.w R15
reti

c_exit:
jmp 0xF87A

ORG 0xFFE0
dw other_ISR
dw other_ISR
dw other_ISR
dw other_ISR
dw other_ISR
dw other_ISR
dw other_ISR
dw other_ISR
dw other_ISR
dw TA0_ISR
dw other_ISR
dw other_ISR
dw other_ISR
dw other_ISR
dw other_ISR
dw c_start
END

--- In m...@yahoogroups.com, "old_cow_yellow" wrote:
>
> The code seems okay. The LED should blink ~10 times per second. If you change the +=50000 to +=5000, it should blink ~100 times per second. Can you tell the difference?
>
> If you change it to too small a number, you will be back to ~10 times per second. May be that is what confused you.
>
> --- In m...@yahoogroups.com, "charper_99" wrote:
> >
> > --- In m...@yahoogroups.com, "old_cow_yellow" wrote:
> > >
> > > Can you show us what assembly or machine code mspgcc generates? It should not be much more than 100 bytes. A hex memory dump of the lowest address part of the Flash will do.
> > >
> > > Also what are at 0xFFF2-3 and 0xFFFE-F?
> >
> > Thanks for the quick response.
> > Unfortunately, I don't think it's possible to generate a nice human-readable opcode output. Unless I'm missing something, there's nothing as high up as 0xFFF23 Here's the entire hex dump:
> >
> > :10F8000031408002B240805A20013F4000000F93F7
> > :10F8100005242F839F4F7CF80002FB233F4000000C
> > :10F820000F9304241F83CF430002FC23304036F89B
> > :10F83000304034F80013314080020441B240805A15
> > :10F840002001D2D32200B24010006201B24050C366
> > :10F850007201B2402002600132D0180030407AF8C4
> > :10F860000F1205120412D2E321003F4050C3825F01
> > :0CF870007201344135413F410013FF3F5D
> > :10FFE00030F830F830F830F830F830F830F830F8D1
> > :10FFF00030F860F830F830F830F830F830F800F8C1
> > :040000030000F80001
> > :00000001FF
>

------------------------------------

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

--- In m...@yahoogroups.com, "old_cow_yellow" wrote:
>
> The code seems okay. The LED should blink ~10 times per second. If you change the +=50000 to +=5000, it should blink ~100 times per second. Can you tell the difference?
>
> If you change it to too small a number, you will be back to ~10 times per second. May be that is what confused you.
No, there is no visible difference between 50,000 and 5,000. I am confused about your second comment, however. How would a smaller value begin to increase the delay further? But either way, nothing seems to have changed.

Also, if it's not derailing the original question too far, what tool did you use to get opcode out of that hex dump?

------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

I think the question was aimed at you to realize if you can tell the difference between a led blinking at 10Hz and 100Hz, I guess the ambient light might influence what you see too. The fact you don't "see" the difference doesn't mean there isn't any. How slow has a led to blink so your eye can see if it is blinking or it is permanently on? you can modify the program and add a software counter to blink the led every 10 or 100 interrupts, then you will see the difference.

// Timer A0 interrupt service routine
#pragma vector=TIMERA0_VECTOR
__interrupt void Timer_A (void)
{
static unsigned int counter=10;
if (!(--counter)) // Counter=0?
{
count = 10;
P1OUT ^= 0x01; // Toggle P1.0
}
CCR0 += 50000; // Add Offset to CCR0
}

Hint: move your led (or protoboard) fast between two points, you should see it moving in discrete steps if it is blinking not too fast.

Regards,
Michael K.

--- In m...@yahoogroups.com, "charper_99" wrote:
>
> --- In m...@yahoogroups.com, "old_cow_yellow" wrote:
> >
> > The code seems okay. The LED should blink ~10 times per second. If you change the +=50000 to +=5000, it should blink ~100 times per second. Can you tell the difference?
> >
> > If you change it to too small a number, you will be back to ~10 times per second. May be that is what confused you.
> No, there is no visible difference between 50,000 and 5,000. I am confused about your second comment, however. How would a smaller value begin to increase the delay further? But either way, nothing seems to have changed.
>
> Also, if it's not derailing the original question too far, what tool did you use to get opcode out of that hex dump?
>
------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

No, it's blinking in very noticeably discrete steps in both cases. I'd estimate well under 10 Hz- maybe 3 to 5. It's about what I'd expect to see on some moderately loaded networking gear if that helps to visualize it. If it's still an issue I can get a scope shot of it later tonight.

--- In m...@yahoogroups.com, "tintronic" wrote:
>
> I think the question was aimed at you to realize if you can tell the difference between a led blinking at 10Hz and 100Hz, I guess the ambient light might influence what you see too. The fact you don't "see" the difference doesn't mean there isn't any. How slow has a led to blink so your eye can see if it is blinking or it is permanently on? you can modify the program and add a software counter to blink the led every 10 or 100 interrupts, then you will see the difference.
------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

Just a stupid question, but you did change the value from 50000 to 5000 in the ISR, not the initialization, right?

you could also monitor more than one pin output and use
P1OUT++;
instead of
P1OUT ^= 0x01;

Or try inverting the LEDs polarity, or put a second led + resistor to the other power rail, as to see if when it is off the pin output is low or third stated (input).

Another stupid question: are you sure you are editing the same file you're compiling and writing to the MSP, and saving the edit before doing that?

try reading the MSP program back and see if the mov.w #0xC350,R15 has changed the 0xC350 value to 0x1388.

You can also use another led to show you the status of BIT3 of CCR0 (toggles if +=5000, or stays off if +=50000).

Michael K.

--- In m...@yahoogroups.com, "charper_99" wrote:
>
> No, it's blinking in very noticeably discrete steps in both cases. I'd estimate well under 10 Hz- maybe 3 to 5. It's about what I'd expect to see on some moderately loaded networking gear if that helps to visualize it. If it's still an issue I can get a scope shot of it later tonight.
>
> --- In m...@yahoogroups.com, "tintronic" wrote:
> >
> > I think the question was aimed at you to realize if you can tell the difference between a led blinking at 10Hz and 100Hz, I guess the ambient light might influence what you see too. The fact you don't "see" the difference doesn't mean there isn't any. How slow has a led to blink so your eye can see if it is blinking or it is permanently on? you can modify the program and add a software counter to blink the led every 10 or 100 interrupts, then you will see the difference.
>
------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

Yes, I'm changing the value in the interrupt.

I thought about the issue of uploading the wrong file. I've reassured myself the correct file is going out by commenting out lines of code and verifying the change.

As for changing hardware around - I'm simply using the ez430 board right now. It doesn't mean I can't do it, but it's inconvenient.

For verifying the opcode, do you know how yellow cow turned my hex dump into a more readable format? I remember (from programming an Msp430 about 2 years ago for work) that IAR spits out some nice opcode for debugging - but afaik mspgcc/eclipse won't do that.
--- In m...@yahoogroups.com, "tintronic" wrote:
>
> Just a stupid question, but you did change the value from 50000 to 5000 in the ISR, not the initialization, right?
>
> you could also monitor more than one pin output and use
> P1OUT++;
> instead of
> P1OUT ^= 0x01;
>
> Or try inverting the LEDs polarity, or put a second led + resistor to the other power rail, as to see if when it is off the pin output is low or third stated (input).
>
> Another stupid question: are you sure you are editing the same file you're compiling and writing to the MSP, and saving the edit before doing that?
>
> try reading the MSP program back and see if the mov.w #0xC350,R15 has changed the 0xC350 value to 0x1388.
>
> You can also use another led to show you the status of BIT3 of CCR0 (toggles if +=5000, or stays off if +=50000).
>
> Michael K.
>
> --- In m...@yahoogroups.com, "charper_99" wrote:
> >
> > No, it's blinking in very noticeably discrete steps in both cases. I'd estimate well under 10 Hz- maybe 3 to 5. It's about what I'd expect to see on some moderately loaded networking gear if that helps to visualize it. If it's still an issue I can get a scope shot of it later tonight.
> >
> > --- In m...@yahoogroups.com, "tintronic" wrote:
> > >
> > > I think the question was aimed at you to realize if you can tell the difference between a led blinking at 10Hz and 100Hz, I guess the ambient light might influence what you see too. The fact you don't "see" the difference doesn't mean there isn't any. How slow has a led to blink so your eye can see if it is blinking or it is permanently on? you can modify the program and add a software counter to blink the led every 10 or 100 interrupts, then you will see the difference.
>

------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

You may have hit the problem with your 'correct file' comment. I went through that procedure again and nothing changed. I'll have to take a better look at my eclipse environment. I must have screwed up something in the middle of all this. Thanks for forcing me to verify the 'stupid things' again.

--- In m...@yahoogroups.com, "tintronic" wrote:
>
> Just a stupid question, but you did change the value from 50000 to 5000 in the ISR, not the initialization, right?
>
> you could also monitor more than one pin output and use
> P1OUT++;
> instead of
> P1OUT ^= 0x01;
>
> Or try inverting the LEDs polarity, or put a second led + resistor to the other power rail, as to see if when it is off the pin output is low or third stated (input).
>
> Another stupid question: are you sure you are editing the same file you're compiling and writing to the MSP, and saving the edit before doing that?
>
> try reading the MSP program back and see if the mov.w #0xC350,R15 has changed the 0xC350 value to 0x1388.
>
> You can also use another led to show you the status of BIT3 of CCR0 (toggles if +=5000, or stays off if +=50000).
>
> Michael K.
>
> --- In m...@yahoogroups.com, "charper_99" wrote:
> >
> > No, it's blinking in very noticeably discrete steps in both cases. I'd estimate well under 10 Hz- maybe 3 to 5. It's about what I'd expect to see on some moderately loaded networking gear if that helps to visualize it. If it's still an issue I can get a scope shot of it later tonight.
> >
> > --- In m...@yahoogroups.com, "tintronic" wrote:
> > >
> > > I think the question was aimed at you to realize if you can tell the difference between a led blinking at 10Hz and 100Hz, I guess the ambient light might influence what you see too. The fact you don't "see" the difference doesn't mean there isn't any. How slow has a led to blink so your eye can see if it is blinking or it is permanently on? you can modify the program and add a software counter to blink the led every 10 or 100 interrupts, then you will see the difference.
>

------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

Hi,
First, one thing is important; in msp430 timer module(timer A module), TAIFG will be set when TAR equals to zero while counting and CCIFG for each timer channel will be set when TAR equals to TACCR0(for timer A module). As it is seen from your code; u have choosen continuous mode for counting and you have choosen a number for TACCR0, 50000. Why do you use "TACCR0 += 50000" ? Do you want that led toggling to be done for every 50000 cycles ? If so; first you must choose up mode for counting and the reason is that; TAR counts up to 65536 and then back to zero in continuous mode and whatever number you load into TACCR0 can be equal to TAR only once in a continuous mode period(65536 cycles). Your period will be actually 65536 cycles although u have choosen 50000. And; you must use TACCR0 = 50000 instead of using TACCR0 += 50000 because; your TACCR0 value profile will be like that otherwise; 50000, 34464(50000+50000-65536), 18928(34464+50000-65536), 3392 and so on... As you see what you want(50000 cycle period) will be deteriorated.
--- In m...@yahoogroups.com, "charper_99" wrote:
>
> You may have hit the problem with your 'correct file' comment. I went through that procedure again and nothing changed. I'll have to take a better look at my eclipse environment. I must have screwed up something in the middle of all this. Thanks for forcing me to verify the 'stupid things' again.
>
> --- In m...@yahoogroups.com, "tintronic" wrote:
> >
> > Just a stupid question, but you did change the value from 50000 to 5000 in the ISR, not the initialization, right?
> >
> > you could also monitor more than one pin output and use
> > P1OUT++;
> > instead of
> > P1OUT ^= 0x01;
> >
> > Or try inverting the LEDs polarity, or put a second led + resistor to the other power rail, as to see if when it is off the pin output is low or third stated (input).
> >
> > Another stupid question: are you sure you are editing the same file you're compiling and writing to the MSP, and saving the edit before doing that?
> >
> > try reading the MSP program back and see if the mov.w #0xC350,R15 has changed the 0xC350 value to 0x1388.
> >
> > You can also use another led to show you the status of BIT3 of CCR0 (toggles if +=5000, or stays off if +=50000).
> >
> > Michael K.
> >
> > --- In m...@yahoogroups.com, "charper_99" wrote:
> > >
> > > No, it's blinking in very noticeably discrete steps in both cases. I'd estimate well under 10 Hz- maybe 3 to 5. It's about what I'd expect to see on some moderately loaded networking gear if that helps to visualize it. If it's still an issue I can get a scope shot of it later tonight.
> > >
> > > --- In m...@yahoogroups.com, "tintronic" wrote:
> > > >
> > > > I think the question was aimed at you to realize if you can tell the difference between a led blinking at 10Hz and 100Hz, I guess the ambient light might influence what you see too. The fact you don't "see" the difference doesn't mean there isn't any. How slow has a led to blink so your eye can see if it is blinking or it is permanently on? you can modify the program and add a software counter to blink the led every 10 or 100 interrupts, then you will see the difference.
> > >
>

------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

Thanks for the help but I believe you are misinformed. First off, this code is directly from one of TI's examples. According to TI's family documentation continuous mode counts up to 16 bits (0xFFFF) continuously and overflows back to zero. Setting TACCR0 + x will always catch the timer at 'whatever + x' as it should, because TACCR0 is a 16-bit register that will overflow just like the timer.

--- In m...@yahoogroups.com, "jedi_erdi" wrote:
>
> Hi,
> First, one thing is important; in msp430 timer module(timer A module), TAIFG will be set when TAR equals to zero while counting and CCIFG for each timer channel will be set when TAR equals to TACCR0(for timer A module). As it is seen from your code; u have choosen continuous mode for counting and you have choosen a number for TACCR0, 50000. Why do you use "TACCR0 += 50000" ? Do you want that led toggling to be done for every 50000 cycles ? If so; first you must choose up mode for counting and the reason is that; TAR counts up to 65536 and then back to zero in continuous mode and whatever number you load into TACCR0 can be equal to TAR only once in a continuous mode period(65536 cycles). Your period will be actually 65536 cycles although u have choosen 50000. And; you must use TACCR0 = 50000 instead of using TACCR0 += 50000 because; your TACCR0 value profile will be like that otherwise; 50000, 34464(50000+50000-65536), 18928(34464+50000-65536), 3392 and so on... As you see what you want(50000 cycle period) will be deteriorated.

------------------------------------

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

I found the problem (sort of). The flash is no longer erasing.

monitor erase all
Erasing target flash - all... Erased OK

Awesome! So I unplug it (ez430 usb thingy), plug it back in... and it blinks!

When I figure out exactly which one (software/mspgcc, programmer/FET, hardware/target) is not working I'll reply here to help future posterity.

But thank you all for your help, you all seem very knowledgeable and friendly and you have a great community here.

--- In m...@yahoogroups.com, "charper_99" wrote:
>
> You may have hit the problem with your 'correct file' comment. I went through that procedure again and nothing changed. I'll have to take a better look at my eclipse environment. I must have screwed up something in the middle of all this. Thanks for forcing me to verify the 'stupid things' again.
>
> --- In m...@yahoogroups.com, "tintronic" wrote:
> >
> > Just a stupid question, but you did change the value from 50000 to 5000 in the ISR, not the initialization, right?
> >
> > you could also monitor more than one pin output and use
> > P1OUT++;
> > instead of
> > P1OUT ^= 0x01;
> >
> > Or try inverting the LEDs polarity, or put a second led + resistor to the other power rail, as to see if when it is off the pin output is low or third stated (input).
> >
> > Another stupid question: are you sure you are editing the same file you're compiling and writing to the MSP, and saving the edit before doing that?
> >
> > try reading the MSP program back and see if the mov.w #0xC350,R15 has changed the 0xC350 value to 0x1388.
> >
> > You can also use another led to show you the status of BIT3 of CCR0 (toggles if +=5000, or stays off if +=50000).
> >
> > Michael K.
> >
> > --- In m...@yahoogroups.com, "charper_99" wrote:
> > >
> > > No, it's blinking in very noticeably discrete steps in both cases. I'd estimate well under 10 Hz- maybe 3 to 5. It's about what I'd expect to see on some moderately loaded networking gear if that helps to visualize it. If it's still an issue I can get a scope shot of it later tonight.
> > >
> > > --- In m...@yahoogroups.com, "tintronic" wrote:
> > > >
> > > > I think the question was aimed at you to realize if you can tell the difference between a led blinking at 10Hz and 100Hz, I guess the ambient light might influence what you see too. The fact you don't "see" the difference doesn't mean there isn't any. How slow has a led to blink so your eye can see if it is blinking or it is permanently on? you can modify the program and add a software counter to blink the led every 10 or 100 interrupts, then you will see the difference.
> > >
>

------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

Here are my answers to your earlier questions.

a) I used IAR KickStart to read your Intel hex dump into the Simulator, use the Disassembler to show it on screen. copy-past to NotePad, and hand edited it. I think gcc has much better ways to do this.

b) I think if you change +=50000 to e.g. +=20, the effect will be half period of 65570 clocks instead of 20 clocks. The reason is, it takes more than 20 clocks for the ISR to change CCR1 after it matches TAR.

--- In m...@yahoogroups.com, "charper_99" wrote:
>
> I found the problem (sort of). The flash is no longer erasing.
>
> monitor erase all
> Erasing target flash - all... Erased OK
>
> Awesome! So I unplug it (ez430 usb thingy), plug it back in... and it blinks!
>
> When I figure out exactly which one (software/mspgcc, programmer/FET, hardware/target) is not working I'll reply here to help future posterity.
>
> But thank you all for your help, you all seem very knowledgeable and friendly and you have a great community here.
>
> --- In m...@yahoogroups.com, "charper_99" wrote:
> >
> > You may have hit the problem with your 'correct file' comment. I went through that procedure again and nothing changed. I'll have to take a better look at my eclipse environment. I must have screwed up something in the middle of all this. Thanks for forcing me to verify the 'stupid things' again.
> >
> > --- In m...@yahoogroups.com, "tintronic" wrote:
> > >
> > > Just a stupid question, but you did change the value from 50000 to 5000 in the ISR, not the initialization, right?
> > >
> > > you could also monitor more than one pin output and use
> > > P1OUT++;
> > > instead of
> > > P1OUT ^= 0x01;
> > >
> > > Or try inverting the LEDs polarity, or put a second led + resistor to the other power rail, as to see if when it is off the pin output is low or third stated (input).
> > >
> > > Another stupid question: are you sure you are editing the same file you're compiling and writing to the MSP, and saving the edit before doing that?
> > >
> > > try reading the MSP program back and see if the mov.w #0xC350,R15 has changed the 0xC350 value to 0x1388.
> > >
> > > You can also use another led to show you the status of BIT3 of CCR0 (toggles if +=5000, or stays off if +=50000).
> > >
> > > Michael K.
> > >
> > > --- In m...@yahoogroups.com, "charper_99" wrote:
> > > >
> > > > No, it's blinking in very noticeably discrete steps in both cases. I'd estimate well under 10 Hz- maybe 3 to 5. It's about what I'd expect to see on some moderately loaded networking gear if that helps to visualize it. If it's still an issue I can get a scope shot of it later tonight.
> > > >
> > > > --- In m...@yahoogroups.com, "tintronic" wrote:
> > > > >
> > > > > I think the question was aimed at you to realize if you can tell the difference between a led blinking at 10Hz and 100Hz, I guess the ambient light might influence what you see too. The fact you don't "see" the difference doesn't mean there isn't any. How slow has a led to blink so your eye can see if it is blinking or it is permanently on? you can modify the program and add a software counter to blink the led every 10 or 100 interrupts, then you will see the difference.
> > > >
> > >
>

------------------------------------

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

Hi,
TI's documentation has good sample codes but TI may make mistakes too, i tried one of the sample codes as "TACCR0+=x" but it did not work as it was supposed to. Also, when you add some number to TACCR0, it will get a new value which is "TACCR0_new = (TACCR0+x)%65536" so mathematically it is impossible for the TACCR0 to catch always the same number x. I tried it and saw that TI's documentation is unfortutunately wrong at that point.
--- In m...@yahoogroups.com, "charper_99" wrote:
>
> I found the problem (sort of). The flash is no longer erasing.
>
> monitor erase all
> Erasing target flash - all... Erased OK
>
> Awesome! So I unplug it (ez430 usb thingy), plug it back in... and it blinks!
>
> When I figure out exactly which one (software/mspgcc, programmer/FET, hardware/target) is not working I'll reply here to help future posterity.
>
> But thank you all for your help, you all seem very knowledgeable and friendly and you have a great community here.
>
> --- In m...@yahoogroups.com, "charper_99" wrote:
> >
> > You may have hit the problem with your 'correct file' comment. I went through that procedure again and nothing changed. I'll have to take a better look at my eclipse environment. I must have screwed up something in the middle of all this. Thanks for forcing me to verify the 'stupid things' again.
> >
> > --- In m...@yahoogroups.com, "tintronic" wrote:
> > >
> > > Just a stupid question, but you did change the value from 50000 to 5000 in the ISR, not the initialization, right?
> > >
> > > you could also monitor more than one pin output and use
> > > P1OUT++;
> > > instead of
> > > P1OUT ^= 0x01;
> > >
> > > Or try inverting the LEDs polarity, or put a second led + resistor to the other power rail, as to see if when it is off the pin output is low or third stated (input).
> > >
> > > Another stupid question: are you sure you are editing the same file you're compiling and writing to the MSP, and saving the edit before doing that?
> > >
> > > try reading the MSP program back and see if the mov.w #0xC350,R15 has changed the 0xC350 value to 0x1388.
> > >
> > > You can also use another led to show you the status of BIT3 of CCR0 (toggles if +=5000, or stays off if +=50000).
> > >
> > > Michael K.
> > >
> > > --- In m...@yahoogroups.com, "charper_99" wrote:
> > > >
> > > > No, it's blinking in very noticeably discrete steps in both cases. I'd estimate well under 10 Hz- maybe 3 to 5. It's about what I'd expect to see on some moderately loaded networking gear if that helps to visualize it. If it's still an issue I can get a scope shot of it later tonight.
> > > >
> > > > --- In m...@yahoogroups.com, "tintronic" wrote:
> > > > >
> > > > > I think the question was aimed at you to realize if you can tell the difference between a led blinking at 10Hz and 100Hz, I guess the ambient light might influence what you see too. The fact you don't "see" the difference doesn't mean there isn't any. How slow has a led to blink so your eye can see if it is blinking or it is permanently on? you can modify the program and add a software counter to blink the led every 10 or 100 interrupts, then you will see the difference.
> > > >
> > >
>

------------------------------------

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

Yes, TI sample codes do have mistakes. But the one the OP quoted seems okay to me. I checked the machine code generated by gccmsp, and it is okay too.

I am curious about which TI sample code you found mathematically impossible.

--- In m...@yahoogroups.com, "jedi_erdi" wrote:
>
> Hi,
> TI's documentation has good sample codes but TI may make mistakes too, i tried one of the sample codes as "TACCR0+=x" but it did not work as it was supposed to. Also, when you add some number to TACCR0, it will get a new value which is "TACCR0_new = (TACCR0+x)%65536" so mathematically it is impossible for the TACCR0 to catch always the same number x. I tried it and saw that TI's documentation is unfortutunately wrong at that point.
> --- In m...@yahoogroups.com, "charper_99" wrote:
> >
> > I found the problem (sort of). The flash is no longer erasing.
> >
> > monitor erase all
> > Erasing target flash - all... Erased OK
> >
> > Awesome! So I unplug it (ez430 usb thingy), plug it back in... and it blinks!
> >
> > When I figure out exactly which one (software/mspgcc, programmer/FET, hardware/target) is not working I'll reply here to help future posterity.
> >
> > But thank you all for your help, you all seem very knowledgeable and friendly and you have a great community here.
> >
> > --- In m...@yahoogroups.com, "charper_99" wrote:
> > >
> > > You may have hit the problem with your 'correct file' comment. I went through that procedure again and nothing changed. I'll have to take a better look at my eclipse environment. I must have screwed up something in the middle of all this. Thanks for forcing me to verify the 'stupid things' again.
> > >
> > > --- In m...@yahoogroups.com, "tintronic" wrote:
> > > >
> > > > Just a stupid question, but you did change the value from 50000 to 5000 in the ISR, not the initialization, right?
> > > >
> > > > you could also monitor more than one pin output and use
> > > > P1OUT++;
> > > > instead of
> > > > P1OUT ^= 0x01;
> > > >
> > > > Or try inverting the LEDs polarity, or put a second led + resistor to the other power rail, as to see if when it is off the pin output is low or third stated (input).
> > > >
> > > > Another stupid question: are you sure you are editing the same file you're compiling and writing to the MSP, and saving the edit before doing that?
> > > >
> > > > try reading the MSP program back and see if the mov.w #0xC350,R15 has changed the 0xC350 value to 0x1388.
> > > >
> > > > You can also use another led to show you the status of BIT3 of CCR0 (toggles if +=5000, or stays off if +=50000).
> > > >
> > > > Michael K.
> > > >
> > > > --- In m...@yahoogroups.com, "charper_99" wrote:
> > > > >
> > > > > No, it's blinking in very noticeably discrete steps in both cases. I'd estimate well under 10 Hz- maybe 3 to 5. It's about what I'd expect to see on some moderately loaded networking gear if that helps to visualize it. If it's still an issue I can get a scope shot of it later tonight.
> > > > >
> > > > > --- In m...@yahoogroups.com, "tintronic" wrote:
> > > > > >
> > > > > > I think the question was aimed at you to realize if you can tell the difference between a led blinking at 10Hz and 100Hz, I guess the ambient light might influence what you see too. The fact you don't "see" the difference doesn't mean there isn't any. How slow has a led to blink so your eye can see if it is blinking or it is permanently on? you can modify the program and add a software counter to blink the led every 10 or 100 interrupts, then you will see the difference.
> > > > >
> > > >
> > >
>

------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

charper_99 wrote:
> I found the problem (sort of). The flash is no longer erasing.
>
> monitor erase all
> Erasing target flash - all... Erased OK
>

Hi,
I'm not sure why you are not getting the system to follow through. You
should be able to write the new code to the micro, run it, stop it and
examine memory to see what is going on.

If you have a doubt about what is being loaded you can keep a bat the
makes on the command line like:

msp430-gcc -mmcu=msp430x1612 -mendup-at=main -Os -g3 -Wall -c
-fmessage-length=0 -MMD -MP -MF "main.d" -MT"main.d" -o "main.o" "../main.c"
msp430-gcc -mmcu=msp430x1612 -o"test.elf" ./main.o ./setdco.o
msp430-objdump -S test.elf >test.lst

And you will know what is in the .elf. Or, just check the modified time
on your objects and elf after you compile.

And that last line will create an assembly listing with the C source
that produced it! Very handy.

But you should not have to unplug and plug your target to get it to run
your new code. It does mean you code is in there and starting the debug
session should do it.

Best, Dan.
(Also, someone else gave me a heads up here, if you don't want to
disturb what is in flash, use: monitor erase main)

------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

Jedi,
I see too many "you must" in your post.
The way the OP is doing it has absolutely nothing wrong and he doesn't need to change anything in his code. The whole code is consistent. You need to understand what the posted code does prior to posting any change to it.

By changing the count mode, of course the rest of the code won't make any sense, so your comparison afterwards is nonsense. You can't change the count mode and then explain why the rest of the code won't work, YOU CHANGED THE COUNT MODE!

The method you're proposing is just a different way to do it, that's all. He doesn't need to change it. I myself use that technique on some projects where I need a different frequency than the Timer frequency. After all, it's just an example and I hardly think that is all he will be using the MSP for, otherwise he "must use an NE555" ;-)

But in your example, you need to use 49999 and not 50000, because in continuous mode TAR is cleared in the next count after TAR matches TACCR0.

Regards,
Michael K.

--- In m...@yahoogroups.com, "jedi_erdi" wrote:
>
> Hi,
> First, one thing is important; in msp430 timer module(timer A module), TAIFG will be set when TAR equals to zero while counting and CCIFG for each timer channel will be set when TAR equals to TACCR0(for timer A module). As it is seen from your code; u have choosen continuous mode for counting and you have choosen a number for TACCR0, 50000. Why do you use "TACCR0 += 50000" ? Do you want that led toggling to be done for every 50000 cycles ? If so; first you must choose up mode for counting and the reason is that; TAR counts up to 65536 and then back to zero in continuous mode and whatever number you load into TACCR0 can be equal to TAR only once in a continuous mode period(65536 cycles). Your period will be actually 65536 cycles although u have choosen 50000. And; you must use TACCR0 = 50000 instead of using TACCR0 += 50000 because; your TACCR0 value profile will be like that otherwise; 50000, 34464(50000+50000-65536), 18928(34464+50000-65536), 3392 and so on... As you see what you want(50000 cycle period) will be deteriorated.
> --- In m...@yahoogroups.com, "charper_99" wrote:
> >
> > You may have hit the problem with your 'correct file' comment. I went through that procedure again and nothing changed. I'll have to take a better look at my eclipse environment. I must have screwed up something in the middle of all this. Thanks for forcing me to verify the 'stupid things' again.
> >
> > --- In m...@yahoogroups.com, "tintronic" wrote:
> > >
> > > Just a stupid question, but you did change the value from 50000 to 5000 in the ISR, not the initialization, right?
> > >
> > > you could also monitor more than one pin output and use
> > > P1OUT++;
> > > instead of
> > > P1OUT ^= 0x01;
> > >
> > > Or try inverting the LEDs polarity, or put a second led + resistor to the other power rail, as to see if when it is off the pin output is low or third stated (input).
> > >
> > > Another stupid question: are you sure you are editing the same file you're compiling and writing to the MSP, and saving the edit before doing that?
> > >
> > > try reading the MSP program back and see if the mov.w #0xC350,R15 has changed the 0xC350 value to 0x1388.
> > >
> > > You can also use another led to show you the status of BIT3 of CCR0 (toggles if +=5000, or stays off if +=50000).
> > >
> > > Michael K.
> > >
> > > --- In m...@yahoogroups.com, "charper_99" wrote:
> > > >
> > > > No, it's blinking in very noticeably discrete steps in both cases. I'd estimate well under 10 Hz- maybe 3 to 5. It's about what I'd expect to see on some moderately loaded networking gear if that helps to visualize it. If it's still an issue I can get a scope shot of it later tonight.
> > > >
> > > > --- In m...@yahoogroups.com, "tintronic" wrote:
> > > > >
> > > > > I think the question was aimed at you to realize if you can tell the difference between a led blinking at 10Hz and 100Hz, I guess the ambient light might influence what you see too. The fact you don't "see" the difference doesn't mean there isn't any. How slow has a led to blink so your eye can see if it is blinking or it is permanently on? you can modify the program and add a software counter to blink the led every 10 or 100 interrupts, then you will see the difference.
> > > >
> > >
>

------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

tintronic wrote:
"Jedi,
I see too many "you must" in your post.
The way the OP is doing it has absolutely nothing wrong and he doesn't need to
change anything in his code. The whole code is consistent. You need to
understand what the posted code does prior to posting any change to it."
As i understood the led blink period is not effected by the change in x of "TACCR0 += x" and i tried to explain why it wont effect by giving an example like "up mode"
Of course it is not a "must" maybe i would say "it should be better" instead of "must".

old_cow_yellow wrote:
"I am curious about which TI sample code you found mathematically impossible."
Some sample code related with timer_A in the zip file "slau149d".

--- In m...@yahoogroups.com, "old_cow_yellow" wrote:
>
> Yes, TI sample codes do have mistakes. But the one the OP quoted seems okay to me. I checked the machine code generated by gccmsp, and it is okay too.
>
> I am curious about which TI sample code you found mathematically impossible.
>
> --- In m...@yahoogroups.com, "jedi_erdi" wrote:
> >
> > Hi,
> > TI's documentation has good sample codes but TI may make mistakes too, i tried one of the sample codes as "TACCR0+=x" but it did not work as it was supposed to. Also, when you add some number to TACCR0, it will get a new value which is "TACCR0_new = (TACCR0+x)%65536" so mathematically it is impossible for the TACCR0 to catch always the same number x. I tried it and saw that TI's documentation is unfortutunately wrong at that point.
> >
> >
> > --- In m...@yahoogroups.com, "charper_99" wrote:
> > >
> > > I found the problem (sort of). The flash is no longer erasing.
> > >
> > > monitor erase all
> > > Erasing target flash - all... Erased OK
> > >
> > > Awesome! So I unplug it (ez430 usb thingy), plug it back in... and it blinks!
> > >
> > > When I figure out exactly which one (software/mspgcc, programmer/FET, hardware/target) is not working I'll reply here to help future posterity.
> > >
> > > But thank you all for your help, you all seem very knowledgeable and friendly and you have a great community here.
> > >
> > > --- In m...@yahoogroups.com, "charper_99" wrote:
> > > >
> > > > You may have hit the problem with your 'correct file' comment. I went through that procedure again and nothing changed. I'll have to take a better look at my eclipse environment. I must have screwed up something in the middle of all this. Thanks for forcing me to verify the 'stupid things' again.
> > > >
> > > > --- In m...@yahoogroups.com, "tintronic" wrote:
> > > > >
> > > > > Just a stupid question, but you did change the value from 50000 to 5000 in the ISR, not the initialization, right?
> > > > >
> > > > > you could also monitor more than one pin output and use
> > > > > P1OUT++;
> > > > > instead of
> > > > > P1OUT ^= 0x01;
> > > > >
> > > > > Or try inverting the LEDs polarity, or put a second led + resistor to the other power rail, as to see if when it is off the pin output is low or third stated (input).
> > > > >
> > > > > Another stupid question: are you sure you are editing the same file you're compiling and writing to the MSP, and saving the edit before doing that?
> > > > >
> > > > > try reading the MSP program back and see if the mov.w #0xC350,R15 has changed the 0xC350 value to 0x1388.
> > > > >
> > > > > You can also use another led to show you the status of BIT3 of CCR0 (toggles if +=5000, or stays off if +=50000).
> > > > >
> > > > > Michael K.
> > > > >
> > > > > --- In m...@yahoogroups.com, "charper_99" wrote:
> > > > > >
> > > > > > No, it's blinking in very noticeably discrete steps in both cases. I'd estimate well under 10 Hz- maybe 3 to 5. It's about what I'd expect to see on some moderately loaded networking gear if that helps to visualize it. If it's still an issue I can get a scope shot of it later tonight.
> > > > > >
> > > > > > --- In m...@yahoogroups.com, "tintronic" wrote:
> > > > > > >
> > > > > > > I think the question was aimed at you to realize if you can tell the difference between a led blinking at 10Hz and 100Hz, I guess the ambient light might influence what you see too. The fact you don't "see" the difference doesn't mean there isn't any. How slow has a led to blink so your eye can see if it is blinking or it is permanently on? you can modify the program and add a software counter to blink the led every 10 or 100 interrupts, then you will see the difference.
> > > > > >
> > > > >
> > > >
> > >
>

------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

> As i understood the led blink period is not effected by the change
> in x of "TACCR0 += x" and i tried to explain why it wont effect by
> giving an example like "up mode".
The problem is you started by assuming that. You didn't stop to try to understand what the code was doing. With all the effort and step by step explaining you did to explain why it wouldn't work in UP mode, I don't imagine you will have any trouble understanding why the code does work, perfectly, in continuous mode.

The toggle period is affected in the way intended, because the counter is working in CONTINUOUS mode. The value of TACCR0 would affect the timer period in UP mode, but not in Continuous mode. The code uses TACCR0 as if it were TACCR1 or TACCR2.
Even in UP mode, "TACCR0 += x" would affect the blink period, but not in the way intended.

But the point is you can't explain why it won't work by using a different count mode. It would be like explaining why an SPI code won't work by changing the serial mode to UART. That is nonsense.

Michael K.

--- In m...@yahoogroups.com, "jedi_erdi" wrote:
>
> tintronic wrote:
> "Jedi,
> I see too many "you must" in your post.
> The way the OP is doing it has absolutely nothing wrong and he doesn't need to
> change anything in his code. The whole code is consistent. You need to
> understand what the posted code does prior to posting any change to it."
> As i understood the led blink period is not effected by the change in x of "TACCR0 += x" and i tried to explain why it wont effect by giving an example like "up mode"
> Of course it is not a "must" maybe i would say "it should be better" instead of "must".
>
> old_cow_yellow wrote:
> "I am curious about which TI sample code you found mathematically impossible."
> Some sample code related with timer_A in the zip file "slau149d".
>
> --- In m...@yahoogroups.com, "old_cow_yellow" wrote:
> >
> > Yes, TI sample codes do have mistakes. But the one the OP quoted seems okay to me. I checked the machine code generated by gccmsp, and it is okay too.
> >
> > I am curious about which TI sample code you found mathematically impossible.
> >
> > --- In m...@yahoogroups.com, "jedi_erdi" wrote:
> > >
> > > Hi,
> > > TI's documentation has good sample codes but TI may make mistakes too, i tried one of the sample codes as "TACCR0+=x" but it did not work as it was supposed to. Also, when you add some number to TACCR0, it will get a new value which is "TACCR0_new = (TACCR0+x)%65536" so mathematically it is impossible for the TACCR0 to catch always the same number x. I tried it and saw that TI's documentation is unfortutunately wrong at that point.
> > >
> > >
> > > --- In m...@yahoogroups.com, "charper_99" wrote:
> > > >
> > > > I found the problem (sort of). The flash is no longer erasing.
> > > >
> > > > monitor erase all
> > > > Erasing target flash - all... Erased OK
> > > >
> > > > Awesome! So I unplug it (ez430 usb thingy), plug it back in... and it blinks!
> > > >
> > > > When I figure out exactly which one (software/mspgcc, programmer/FET, hardware/target) is not working I'll reply here to help future posterity.
> > > >
> > > > But thank you all for your help, you all seem very knowledgeable and friendly and you have a great community here.
> > > >
> > > > --- In m...@yahoogroups.com, "charper_99" wrote:
> > > > >
> > > > > You may have hit the problem with your 'correct file' comment. I went through that procedure again and nothing changed. I'll have to take a better look at my eclipse environment. I must have screwed up something in the middle of all this. Thanks for forcing me to verify the 'stupid things' again.
> > > > >
> > > > > --- In m...@yahoogroups.com, "tintronic" wrote:
> > > > > >
> > > > > > Just a stupid question, but you did change the value from 50000 to 5000 in the ISR, not the initialization, right?
> > > > > >
> > > > > > you could also monitor more than one pin output and use
> > > > > > P1OUT++;
> > > > > > instead of
> > > > > > P1OUT ^= 0x01;
> > > > > >
> > > > > > Or try inverting the LEDs polarity, or put a second led + resistor to the other power rail, as to see if when it is off the pin output is low or third stated (input).
> > > > > >
> > > > > > Another stupid question: are you sure you are editing the same file you're compiling and writing to the MSP, and saving the edit before doing that?
> > > > > >
> > > > > > try reading the MSP program back and see if the mov.w #0xC350,R15 has changed the 0xC350 value to 0x1388.
> > > > > >
> > > > > > You can also use another led to show you the status of BIT3 of CCR0 (toggles if +=5000, or stays off if +=50000).
> > > > > >
> > > > > > Michael K.
> > > > > >
> > > > > > --- In m...@yahoogroups.com, "charper_99" wrote:
> > > > > > >
> > > > > > > No, it's blinking in very noticeably discrete steps in both cases. I'd estimate well under 10 Hz- maybe 3 to 5. It's about what I'd expect to see on some moderately loaded networking gear if that helps to visualize it. If it's still an issue I can get a scope shot of it later tonight.
> > > > > > >
> > > > > > > --- In m...@yahoogroups.com, "tintronic" wrote:
> > > > > > > >
> > > > > > > > I think the question was aimed at you to realize if you can tell the difference between a led blinking at 10Hz and 100Hz, I guess the ambient light might influence what you see too. The fact you don't "see" the difference doesn't mean there isn't any. How slow has a led to blink so your eye can see if it is blinking or it is permanently on? you can modify the program and add a software counter to blink the led every 10 or 100 interrupts, then you will see the difference.
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
>

------------------------------------

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

You said:
"Some sample code related with timer_A in the zip file "slau149d"

I could not find slau149d.*
Did you mean slaa149d.zip? Which is about something called "Replicator".

--- In m...@yahoogroups.com, "jedi_erdi" wrote:
>
> tintronic wrote:
> "Jedi,
> I see too many "you must" in your post.
> The way the OP is doing it has absolutely nothing wrong and he doesn't need to
> change anything in his code. The whole code is consistent. You need to
> understand what the posted code does prior to posting any change to it."
> As i understood the led blink period is not effected by the change in x of "TACCR0 += x" and i tried to explain why it wont effect by giving an example like "up mode"
> Of course it is not a "must" maybe i would say "it should be better" instead of "must".
>
> old_cow_yellow wrote:
> "I am curious about which TI sample code you found mathematically impossible."
> Some sample code related with timer_A in the zip file "slau149d".
>
> --- In m...@yahoogroups.com, "old_cow_yellow" wrote:
> >
> > Yes, TI sample codes do have mistakes. But the one the OP quoted seems okay to me. I checked the machine code generated by gccmsp, and it is okay too.
> >
> > I am curious about which TI sample code you found mathematically impossible.
> >
> > --- In m...@yahoogroups.com, "jedi_erdi" wrote:
> > >
> > > Hi,
> > > TI's documentation has good sample codes but TI may make mistakes too, i tried one of the sample codes as "TACCR0+=x" but it did not work as it was supposed to. Also, when you add some number to TACCR0, it will get a new value which is "TACCR0_new = (TACCR0+x)%65536" so mathematically it is impossible for the TACCR0 to catch always the same number x. I tried it and saw that TI's documentation is unfortutunately wrong at that point.
> > >
> > >
> > > --- In m...@yahoogroups.com, "charper_99" wrote:
> > > >
> > > > I found the problem (sort of). The flash is no longer erasing.
> > > >
> > > > monitor erase all
> > > > Erasing target flash - all... Erased OK
> > > >
> > > > Awesome! So I unplug it (ez430 usb thingy), plug it back in... and it blinks!
> > > >
> > > > When I figure out exactly which one (software/mspgcc, programmer/FET, hardware/target) is not working I'll reply here to help future posterity.
> > > >
> > > > But thank you all for your help, you all seem very knowledgeable and friendly and you have a great community here.
> > > >
> > > > --- In m...@yahoogroups.com, "charper_99" wrote:
> > > > >
> > > > > You may have hit the problem with your 'correct file' comment. I went through that procedure again and nothing changed. I'll have to take a better look at my eclipse environment. I must have screwed up something in the middle of all this. Thanks for forcing me to verify the 'stupid things' again.
> > > > >
> > > > > --- In m...@yahoogroups.com, "tintronic" wrote:
> > > > > >
> > > > > > Just a stupid question, but you did change the value from 50000 to 5000 in the ISR, not the initialization, right?
> > > > > >
> > > > > > you could also monitor more than one pin output and use
> > > > > > P1OUT++;
> > > > > > instead of
> > > > > > P1OUT ^= 0x01;
> > > > > >
> > > > > > Or try inverting the LEDs polarity, or put a second led + resistor to the other power rail, as to see if when it is off the pin output is low or third stated (input).
> > > > > >
> > > > > > Another stupid question: are you sure you are editing the same file you're compiling and writing to the MSP, and saving the edit before doing that?
> > > > > >
> > > > > > try reading the MSP program back and see if the mov.w #0xC350,R15 has changed the 0xC350 value to 0x1388.
> > > > > >
> > > > > > You can also use another led to show you the status of BIT3 of CCR0 (toggles if +=5000, or stays off if +=50000).
> > > > > >
> > > > > > Michael K.
> > > > > >
> > > > > > --- In m...@yahoogroups.com, "charper_99" wrote:
> > > > > > >
> > > > > > > No, it's blinking in very noticeably discrete steps in both cases. I'd estimate well under 10 Hz- maybe 3 to 5. It's about what I'd expect to see on some moderately loaded networking gear if that helps to visualize it. If it's still an issue I can get a scope shot of it later tonight.
> > > > > > >
> > > > > > > --- In m...@yahoogroups.com, "tintronic" wrote:
> > > > > > > >
> > > > > > > > I think the question was aimed at you to realize if you can tell the difference between a led blinking at 10Hz and 100Hz, I guess the ambient light might influence what you see too. The fact you don't "see" the difference doesn't mean there isn't any. How slow has a led to blink so your eye can see if it is blinking or it is permanently on? you can modify the program and add a software counter to blink the led every 10 or 100 interrupts, then you will see the difference.
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
>

------------------------------------

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

tintronic wrote:
"As i understood the led blink period is not effected by the change
> in x of "TACCR0 += x" and i tried to explain why it wont effect by
> giving an example like "up mode".
The problem is you started by assuming that. You didn't stop to try to
understand what the code was doing. With all the effort and step by step
explaining you did to explain why it wouldn't work in UP mode, I don't imagine
you will have any trouble understanding why the code does work, perfectly, in
continuous mode."
You may be right, here i tried to explain by giving up mode example like suggesting "if you want to change the led blink period
you should better use up mode" but; of course it would be just a suggestion and once after giving the suggestion, notifying that
"if you used even up mode there will still be period deterioration because; CCR0= += x, bla bla bla", the notifying part was the second part of the suggestion.
I see there is no problem for the code in continuous mode and no problem any more.

old_cow_yelleow wrote:
"I could not find slau149d.*"
Sorry i have written wrong and the right one is slac149d.
--- In m...@yahoogroups.com, "old_cow_yellow" wrote:
>
> You said:
> "Some sample code related with timer_A in the zip file "slau149d"
>
> I could not find slau149d.*
> Did you mean slaa149d.zip? Which is about something called "Replicator".
>
> --- In m...@yahoogroups.com, "jedi_erdi" wrote:
> >
> > tintronic wrote:
> > "Jedi,
> > I see too many "you must" in your post.
> > The way the OP is doing it has absolutely nothing wrong and he doesn't need to
> > change anything in his code. The whole code is consistent. You need to
> > understand what the posted code does prior to posting any change to it."
> > As i understood the led blink period is not effected by the change in x of "TACCR0 += x" and i tried to explain why it wont effect by giving an example like "up mode"
> > Of course it is not a "must" maybe i would say "it should be better" instead of "must".
> >
> > old_cow_yellow wrote:
> > "I am curious about which TI sample code you found mathematically impossible."
> > Some sample code related with timer_A in the zip file "slau149d".
> >
> > --- In m...@yahoogroups.com, "old_cow_yellow" wrote:
> > >
> > > Yes, TI sample codes do have mistakes. But the one the OP quoted seems okay to me. I checked the machine code generated by gccmsp, and it is okay too.
> > >
> > > I am curious about which TI sample code you found mathematically impossible.
> > >
> > > --- In m...@yahoogroups.com, "jedi_erdi" wrote:
> > > >
> > > > Hi,
> > > > TI's documentation has good sample codes but TI may make mistakes too, i tried one of the sample codes as "TACCR0+=x" but it did not work as it was supposed to. Also, when you add some number to TACCR0, it will get a new value which is "TACCR0_new = (TACCR0+x)%65536" so mathematically it is impossible for the TACCR0 to catch always the same number x. I tried it and saw that TI's documentation is unfortutunately wrong at that point.
> > > >
> > > >
> > > > --- In m...@yahoogroups.com, "charper_99" wrote:
> > > > >
> > > > > I found the problem (sort of). The flash is no longer erasing.
> > > > >
> > > > > monitor erase all
> > > > > Erasing target flash - all... Erased OK
> > > > >
> > > > > Awesome! So I unplug it (ez430 usb thingy), plug it back in... and it blinks!
> > > > >
> > > > > When I figure out exactly which one (software/mspgcc, programmer/FET, hardware/target) is not working I'll reply here to help future posterity.
> > > > >
> > > > > But thank you all for your help, you all seem very knowledgeable and friendly and you have a great community here.
> > > > >
> > > > > --- In m...@yahoogroups.com, "charper_99" wrote:
> > > > > >
> > > > > > You may have hit the problem with your 'correct file' comment. I went through that procedure again and nothing changed. I'll have to take a better look at my eclipse environment. I must have screwed up something in the middle of all this. Thanks for forcing me to verify the 'stupid things' again.
> > > > > >
> > > > > > --- In m...@yahoogroups.com, "tintronic" wrote:
> > > > > > >
> > > > > > > Just a stupid question, but you did change the value from 50000 to 5000 in the ISR, not the initialization, right?
> > > > > > >
> > > > > > > you could also monitor more than one pin output and use
> > > > > > > P1OUT++;
> > > > > > > instead of
> > > > > > > P1OUT ^= 0x01;
> > > > > > >
> > > > > > > Or try inverting the LEDs polarity, or put a second led + resistor to the other power rail, as to see if when it is off the pin output is low or third stated (input).
> > > > > > >
> > > > > > > Another stupid question: are you sure you are editing the same file you're compiling and writing to the MSP, and saving the edit before doing that?
> > > > > > >
> > > > > > > try reading the MSP program back and see if the mov.w #0xC350,R15 has changed the 0xC350 value to 0x1388.
> > > > > > >
> > > > > > > You can also use another led to show you the status of BIT3 of CCR0 (toggles if +=5000, or stays off if +=50000).
> > > > > > >
> > > > > > > Michael K.
> > > > > > >
> > > > > > > --- In m...@yahoogroups.com, "charper_99" wrote:
> > > > > > > >
> > > > > > > > No, it's blinking in very noticeably discrete steps in both cases. I'd estimate well under 10 Hz- maybe 3 to 5. It's about what I'd expect to see on some moderately loaded networking gear if that helps to visualize it. If it's still an issue I can get a scope shot of it later tonight.
> > > > > > > >
> > > > > > > > --- In m...@yahoogroups.com, "tintronic" wrote:
> > > > > > > > >
> > > > > > > > > I think the question was aimed at you to realize if you can tell the difference between a led blinking at 10Hz and 100Hz, I guess the ambient light might influence what you see too. The fact you don't "see" the difference doesn't mean there isn't any. How slow has a led to blink so your eye can see if it is blinking or it is permanently on? you can modify the program and add a software counter to blink the led every 10 or 100 interrupts, then you will see the difference.
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
>

------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

--- In m...@yahoogroups.com, Dan Bloomquist wrote:
>
> charper_99 wrote:
> > I found the problem (sort of). The flash is no longer erasing.
> >
> > monitor erase all
> > Erasing target flash - all... Erased OK
> >
>
> Hi,
> I'm not sure why you are not getting the system to follow through. You
> should be able to write the new code to the micro, run it, stop it and
> examine memory to see what is going on.
>
> If you have a doubt about what is being loaded you can keep a bat the
> makes on the command line like:
>
> msp430-gcc -mmcu=msp430x1612 -mendup-at=main -Os -g3 -Wall -c
> -fmessage-length=0 -MMD -MP -MF "main.d" -MT"main.d" -o "main.o" "../main.c"
> msp430-gcc -mmcu=msp430x1612 -o"test.elf" ./main.o ./setdco.o
> msp430-objdump -S test.elf >test.lst
>
> And you will know what is in the .elf. Or, just check the modified time
> on your objects and elf after you compile.
>
> And that last line will create an assembly listing with the C source
> that produced it! Very handy.
>
> But you should not have to unplug and plug your target to get it to run
> your new code. It does mean you code is in there and starting the debug
> session should do it.
>
> Best, Dan.
> (Also, someone else gave me a heads up here, if you don't want to
> disturb what is in flash, use: monitor erase main)
>
Thanks for the heads up about the erase main - I'm sure I'll need that one some day. I have had errors (fairly randomly) during debugging about failing to interrupt and such. The hard power reset was the best way to prove to myself there was no witchcraft going on. I.E. the should-be-empty uC was running code. After seeing the results of this, I assume my debug errors were caused by code mismatches between the 430 and eclipse. I'll probably charge into this again during the weekend and figure out exactly what is going on. I'm going to see if I can reproduce this problem with IAR, then maybe with a different target board.

------------------------------------

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

--- In m...@yahoogroups.com, "jedi_erdi" wrote:
>
> Hi,
> TI's documentation has good sample codes but TI may make mistakes too, i tried one of the sample codes as "TACCR0+=x" but it did not work as it was supposed to. Also, when you add some number to TACCR0, it will get a new value which is "TACCR0_new = (TACCR0+x)%65536" so mathematically it is impossible for the TACCR0 to catch always the same number x. I tried it and saw that TI's documentation is unfortutunately wrong at that point.
>

Hi,

I looked into the slac149d.zip as you indicated in your later posting. I found 11 sample codes for TimerA. Only one of them use CCR0 += something. I think it does work as it was supposed to and TI's documentation is fortunately correct in this respect.

Are we talking about the same sample code?

TI Zip file name: SLAC149d.zip
Sample code: msp430x24x.c

//******************************************************************************
// MSP430x24x Demo - Timer_A, Toggle P1.0, CCR0 Cont. Mode ISR, DCO SMCLK
//
// Description: Toggle P1.0 using software and TA_0 ISR. Toggles every
// 50000 SMCLK cycles. SMCLK provides clock source for TACLK.
// During the TA_0 ISR, P1.0 is toggled and 50000 clock cycles are added to
// CCR0. TA_0 ISR is triggered every 50000 cycles. CPU is normally off and
// used only during TA_ISR.
// ACLK = n/a, MCLK = SMCLK = TACLK = default DCO ~1.045Mhz
//
// MSP430F249
// ---------------
// /|\| XIN|-
// | | |
// --|RST XOUT|-
// | |
// | P1.0|-->LED
//
// B. Nisarga
// Texas Instruments Inc.
// September 2007
// Built with CCE Version: 3.2.0 and IAR Embedded Workbench Version: 3.42A
//******************************************************************************

#include

void main(void)
{
WDTCTL = WDTPW + WDTHOLD; // Stop WDT
P1DIR |= 0x01; // P1.0 output
CCTL0 = CCIE; // CCR0 interrupt enabled
CCR0 = 50000;
TACTL = TASSEL_2 + MC_2; // SMCLK, contmode

_BIS_SR(LPM0_bits + GIE); // Enter LPM0 w/ interrupt
}

// Timer A0 interrupt service routine
#pragma vector=TIMERA0_VECTOR
__interrupt void Timer_A (void)
{
P1OUT ^= 0x01; // Toggle P1.0
CCR0 += 50000; // Add Offset to CCR0
}
------------------------------------

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )