Part Number: MSP430F2274
Tool/software: Code Composer Studio
Have been trying to debug a simple example program for the MSP430F2274 device. The example uses timerA in continuous mode and toggles and LED when an interrupt occurs (a.k.a when TAIV = 10). Within the `interrupt void Timer_A(void)` function, I have set a breakpoint at a switch statement, which chooses the operation to be performed depending on the value of TAIV. When entering debug mode the program never stops at the breakpoint, making it appear that the interrupt is never reached. Upon viewing the register, I can confirm that an interrupt has occurred based upon the change in the TAIV register. Is it possible to have a breakpoint set in an interrupt function? If it is, could there be a reason as to why this it is never triggered during my debug session? If not, is there another method of debugging that confirms that the ISR is reached? Ideally, if the ISR can be stepped through it would be much more helpful for future project work using this device.
Furthermore, once the program is run from the debugger, the intended functionality is not happening until the device is disconnected and reconnected to a power source. The problem is that when disconnecting from the USB, the debugger stops working as it no longer has a device that it can reach for its debugging purposes. Is there a reason that this occurs, or is this common with all MSP430 devices? If not, are there any options which can be changed to allow the device to work correctly once the debugger has begun running, without having to disconnect/reconnect it?
WDTCTL = WDTPW + WDTHOLD; // Stop WDT
P1DIR |= 0x01; // P1.0 output
TACTL = TASSEL_2 + MC_2 + TAIE; // SMCLK, contmode, interrupt
__bis_SR_register(GIE); // Enter LPM0 w/ interrupt
// Timer_A3 Interrupt Vector (TAIV) handler
#if defined(__TI_COMPILER_VERSION__) || defined(__IAR_SYSTEMS_ICC__)
__interrupt void Timer_A(void)
void __attribute__ ((interrupt(TIMERA1_VECTOR))) Timer_A (void)
#error Compiler not supported!
switch(TAIV) // Efficient switch-implementation
break; // TACCR1 not used
break; // TACCR2 not used
P1OUT ^= 0x01; // overflow
Thank you for providing the test case. It is very helpful and appreciated.
I set a breakpoint at line 25 and when I run the program, that breakpoint is definitely triggered. Can you provide a screenshot of your CCS IDE? I would like to see specifically the breakpoint set in the editor margin, the corresponding Disassembly view, and also the entire Breakpoints view. Something like the below:
Did you read the CCS Forum Guidelines & FAQ? If not, PLEASE read it. If you haven't read it in awhile, please read it again to see if any updates were made.
Having CCS problems? Check out the CCS Troubleshooting Guide
Looking for CCS Training? Check out the CCS Training Site
Curious about the status of a bug and know the tracking ID? Track it via the public bug tracking portal
NOTE: When a bug is filed and a tracking ID is provided, the thread may then be suggested as "TI Thinks Resolved". Why? Please read the first FAQ of the CCS Forum Guidelines & FAQ
We are glad that we were able to resolve this issue, and will now proceed to close this thread.
If you have further questions related to this thread, you may click "Ask a related question" below. The newly created question will be automatically linked to this question.
In reply to Ki-Soo Lee:
Here is an image of my workspace in CCS. Again, the device will not run as predicted unless the device is disconnected and reconnnected to the USB. Based upon the code provided, there should be multiple interrupts occurring each second, causing the LED to toggle rapidly. Once the program is run, there is nothing happening on the device until it is disconnected and reconnected, or after the debugger has stopped (by pressing the stop icon in the toolbar).
In reply to Sean Kramer:
Sean KramerAgain, the device will not run as predicted unless the device is disconnected and reconnnected to the USB. Based upon the code provided, there should be multiple interrupts occurring each second, causing the LED to toggle rapidly. Once the program is run, there is nothing happening on the device until it is disconnected and reconnected
I just want to confirm that I am running the test case properly. When I load the program, I am at main. When I execute the program, I see the LED toggling rapidly. I assume that the code/device is running correctly. Then when I set a breakpoint at line 25, the debugger immediately halts there (as seen in my screenshot in my prior post). Does this sound right? I did not need to disconnect/reconnect to the USB.
Here is an image that was taken from CCS, notice that it took almost 600 million clock cycles to reach this point, and that although the TAIV register has the value of '0xA' in it, the jump has skipped over the ISR, the LED did not toggle, and the breakpoint was not reached.
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with respect to these materials. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.