Jump to content

msp430 error with capture in P1.5

Recommended Posts

hello everyone, I use P1.5 (timer 0.0) in msp430 launchpad with msp430g2553  for capture mode. but it seems wrong somewhere. it does not work. can anyone show me why it does not work correctly

#include <msp430g2553.h>
#include "uart.h"
#define	trigger		BIT4;
#define	 echo		BIT5;

void timer_init(void);
void do_khoang_cach(void);

unsigned int t1=0, t2=0, delta=0, first_pulse=0;

void main(void)

	P1DIR |= trigger;		
	P1SEL |= echo;			


	while (1)

void timer_init(void){
	TA0CTL = TASSEL_2 + MC_2 ;		
	TA0CCTL0 = CM_3 + CAP + CCIS_0 + SCS+ CCIE;		// falling edge & raising edge, capture mode, capture/compare interrupt enable

void do_khoang_cach(void){

	P1OUT |= trigger;
	P1OUT &= ~trigger;

#pragma vector = TIMER0_A0_VECTOR
__interrupt void timer0(void){

	if (P1IN & BIT5 ==1 )
		t1 = TA0CCR0;

	else {
		t2 = TA0CCR0;
		if (t2 > t1){
			delta = (t2-t1)/58;



Link to post
Share on other sites
  • 1 month later...

I'm guessing you've jumpered P1.4 to P1.5 so that when P1.4 is toggled it will trigger the capture. Does the capture interrupt never fire, or does it run but not print the output, or is the printed output incorrect?


It's not clear exactly where the problem lies, so I'm going to throw out some suggestions which may or may not be relevant.


The condition on the line "if (P1IN & BIT5 ==1)" will never be true, as it is evaluated like so: if (P1IN & (BIT5 ==1)). BIT5 isn't equal to 1, so that becomes if (P1IN & 0), which is always false. You'll need to use parentheses to force the evaluation order.


The test "if (t2 > t1)" will cause you to lose a pulse if the timer wraps around to zero between the rising and falling edges. If you store t1 and t2 in 16 bit unsigned integer variables it will still be safe to calculate (t2-t1) in this situation. Depending on your compiler you might need to switch t1 and t2 to be unsigned short type rather than unsigned int.


Testing P1IN bit 5 to check the state of the input after the capture interrupt is dubious. Some microseconds pass between the rising edge of the pulse being detected and the interrupt service routine starting to execute. In this test program that will be OK as the main loop will be halted before it can clear P1OUT bit 4, but if you hook this up to an external input you might get incorrect readings. If you can spare another CCR it would be better to capture rising and falling edges separately, and only interrupt on the falling edge. Then you would have the rising edge capture in CCR1 (for instance) and the falling edge in CCR0, ready for handling.


Calling UART print functions during the ISR is also not a great idea. It means you'll be stuck in the ISR for a long time and won't be able to process any interrupts until the printing is complete. If the UART code is interrupt-based that could even cause a deadlock.


By the way, I think this topic belongs in "General" rather than "Compilers and IDEs", so a mod may be along to move it over at some point.

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...