This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Code help

Other Parts Discussed in Thread: OMAP-L137

{\rtf1\ansi\ansicpg1252\cocoartf1038\cocoasubrtf320
{\fonttbl\f0\fswiss\fcharset0 Helvetica;}
{\colortbl;\red255\green255\blue255;}
\margl1440\margr1440\vieww9000\viewh8400\viewkind0
\pard\tx720\tx1440\tx2160\tx2880\tx3600\tx4320\tx5040\tx5760\tx6480\tx7200\tx7920\tx8640\ql\qnatural\pardirnatural

\f0\fs24 \cf0 #include <msp430x20x2.h> \
\
#define LED0 BIT0\
#define LED1 BIT6 \
#define BUTTON BIT3\
\
int i, j;\
volatile int interval=0, lastcount=0, count = 0;\
\
int main(void)\
\{\
WDTCTL = WDTPW + WDTHOLD; // Stop watchdog timer\
P1DIR |= (LED0 + LED1); // Set P1.0 to output direction \
// P1.3 must stay at input\
P1OUT &= ~(LED0 + LED1); // set P1.0 to 0 (LED OFF)\
P1IE |= BUTTON; // P1.3 interrupt enabled\
TACCR0 = 32768;\
TACTL = TASSEL_1 + MC_1 + TACLR;\
P1IFG &= ~BUTTON; // P1.3 IFG cleared\
\
\
__enable_interrupt(); // enable all interrupts\
for(;;)\
\{\}\
\}\
\
void test()\
\{\
	P1OUT ^= LED0;\
	count=TAR;\
	interval=count-lastcount;\
	lastcount=count;\
	if(interval<165 && interval>162)\
\{\
P1OUT ^= LED1; // P1.0 = toggle\
\}\
\}\
\
\
#pragma vector=TIMERA0_VECTOR		// Timer A0 interrupt service routine\
__interrupt void Timer_A (void)\
\{\
	\}\
	\
	\
// Port 1 interrupt service routine\
#pragma vector=PORT1_VECTOR\
__interrupt void Port_1(void)\
\{\
	test();\
P1IFG &= ~BUTTON; // P1.3 IFG cleared\
\}}

 

I am running this code on a MSP430 Launchpad, and when I hit the button on P1.3 the red LED goes on and off. When I feed it a 200 Hz square wave pulse it does not light up the green LED as expected.

 

The way I am calculating is...

TACCR0=32768; //32768 counts per second

200 Hz means 5ms time period

Counts in 5 ms = .005*32768 = 163.84 counts

 

Any help will be greatly appreciated.

  • It looks like you might want to be calling the test function from the timer interrupts.  However, you will want to wrap the test function call in an if statement to check to see if the button is active by either testing the button itself or testing the LED controlled by the button.  At least that's what I see.

    Jim Noxon

  • I'd suggest using unsigned int and letting the timer roll over at 0xFFFF, eg.

    volatile unsigned int interval=0, lastcount=0, count = 0;
    ...
    TACTL = TASSEL_2 | MC_1 | TACLR; // Clear timer, up to 0xFFFF continous, use ACLK
    ...

    That should take care of the situation where samples occur before and after the timer reaching 0xFFFF.

    Since the pushbutton works, I would guess that ACLK might not be 32768Hz. Maybe a divider is enabled.

    The documentation states that TAR should not read directly if the timer clock is asynchronous to the CPU clock. I don't understant the doc enough to figure out if ACLK is synchronous with MCLK. You might need to stop, sample, restart the timer or use a software capture.

  • Samples occurring before and after 0xFFFF isn't that big a concern at the moment. I can put a software check on it later in the code if the need be, this is more to test that at least the core functionality works.

     

    The main purpose of the code is to light up the LED at P1.6 if a pulse of 200 Hz was fed at P1.3, it should not light up before that or after.

     

    I can even change that to it should light up only when it is more than 200 Hz, the code would change to 

    if(interval<165)
    {
    }
    
    
    Is there any way to figure out what frequency is the ACLK running at?
    if I changed to "TACTL = TASSEL_2" I would need to solder the external crystal wouldn't I?
    
    
    If I were to do that then to read the TAR register I would need to modify the code to...
    
    
    TACTL = MC_0;
    count=TAR;
    TACTL = MC_1;
    
    
    Is that correct?

  • Oops. Sorry, I got the bits mixed up. I meant MC_1 to MC_2. All book knowledge. Not my processor.

    volatile unsigned int interval=0, lastcount=0, count = 0;
    ...
    TACTL = TASSEL_1 | MC_2 | TACLR; // Clear timer, up to 0xFFFF continous, use ACLK
    ...

    Maybe check the interval vairable after feeding your 200kHz signal. The symptoms imply no timer tick or timer is not at the frequency you think it is. Actually check count as well.

     

  • Yes, I was thinking on the same lines of actually checking the interval variable when I feed it the 200 Hz signal.

    How can I do it on CCS? Is there some way to watch variables and see the value as the program executes.

  • My experience is with the CCS3 on OMAP-L137. On that CCS, I could break or stop and look at variables. Never tried a watch. In theory, you should not need to watch during execution. You be able to feed in the 200Hz signal for a few seconds and then break to look at your global variables (right click or mouse over the variable?).

     

  • You can set up watch points but these are not really "Real Time" as they halt the processor while the IDE queries the necessary information to update the display.  At 200 Hz, this is probably really pushing the ability to use this type of monitoring.  I usually resort to one of two types of monitoring in these types of cases.  1) use a data logging buffer to store information in a manner which will hold some history so you can see what is going on.  2) toggle a GPIO signal at key points in the code to determine if the timing is waht you expecte it to be.

    One thought I've had is might it be better to set up the timer in capture mode and have it count clock ticks between rising and falling edges?  This way, rather than trying to detect an edge in a window, you can merely compare the captured value to the window and know if the pulse is above, below, or within the window.  The ISR could then merely fill in the history buffer for several pulses.  If this part has a DMA, you could use the DMA to fill in the buffer leaving your code to do more useful things.  Just a thought.

    Jim Noxon

  •  The MSP430x2xxx.pdf manual said: “A low-frequency auxiliary clock (ACLK) is driven directly from a common 32-kHz watch crystal. The ACLK can be used for a background real-time clock self wake-up function.”

     

    The actual situation is:

    1)       If you run the sample code provided by TI, “CLK-Test.C” from P1.0 suppose get ACLK 32KHz, but digital oscilloscope will show you it is a very bad un-uniform pulses, it is not a clock signal.  The SMCLK is a very stable 1.08 MHz.

    2)       If you use ACLK as timer clock (set TASSEL_1) the timer counting time T (from 0 to CCR0) varies  all the time. One example set the CCR0=32, T will be 12mS, 61mS, 35mS, 84mS, 67mS… .

    Anyway, I am not say ACLK doesn’t work. But should be very careful and can not use ACLK as time base. I will never use ACLK. 

     

  • Have you solved your problem?  If not, let me know.  I will give you a good code file.  That is my pleasure.

    As I said ACLK is unable to be used by user.  You have to use SMCLK.  You don't need external crystal.

     

  • I haven't been able to write code using the SMCLK because have been busy at work, if you could provide me the code file, that might help me get this done somewhat quicker.

     

    Not like I dont want to try it myself, but I am just not getting the time.

**Attention** This is a public forum