MSP430AFE252 and debugging issues

I changed my LaunchPad to an upgraded one (S/N: R110311315) with not much luck. Neither IAR, nor CCS can debug my circuit correctly. Here are my results:

 

- step debug execution is OK, the changes in the registers and variables can be observed

- free run mode fires no timer interrupt in debug mode, checked with a breakpoint placed in the ISR and also with a LED connected to a pin which should be toggled in the timer ISR - the program flow apparently avoid the ISR

- no timer interrupts until programming cable is removed

- after removing the cable and dis-/reconnecting the supply the circuit works as expected

 

The code:

 

 //******************************************************************************
//  MSP430AFE25x 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
//
//           MSP430AFE25x
//         ---------------
//     /|\|            XIN|-
//      | |               |
//      --|RST        XOUT|-
//        |               |
//        |           P1.0|-->LED
//
//  Naveen Kala
//  Texas Instruments, Inc
//  March 2011
//  Built with IAR Embedded Workbench Version: 5.20.1
//******************************************************************************
#include <msp430afe252.h>

unsigned volatile int count = 0;
void main(void)
{
  WDTCTL = WDTPW + WDTHOLD;                 // Stop WDT
 P2DIR |= BIT0;                            // P2.0 output
  CCTL0 = CCIE;                             // CCR0 interrupt enabled
  CCR0 = 50000;
  TACTL = TASSEL_2 + MC_2;                  // SMCLK, contmode
  
  P2OUT &=~BIT0;
  
  P2OUT |=BIT0;

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

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

Does your application start at all if not under debugger control (free run)?

Since you do not use the normal configuration (MSP powered by LaunchPad in LaunchPad socket), it is possible that you're haveing problems with the supply voltage and/or your reset pin.
The SBW interface attaches to the reset pin, so there is a direct influence onto the behavior of the reset logic.

It is possible that under some circumstances the MSP doesn't start at all (and therefore no interrupts occur).

To ensure the code is running, you should toggle an LED right at the start of main.

Hi Jens,

 

thank you for your reply!

 

Jens-Michael Gross said:

Does your application start at all if not under debugger control (free run)?

You mean that all SBW lines are disconnected, only the voltage supply is connected? Then my answer is yes, with addition that my circuit is working only this way. If I enter into debug mode (CTRL+D in IAR) and press 'Go', the circuit won't work correctly until I quit debug mode, disconnect SBW lines and disconnect/reconnect the supply.

Jens-Michael Gross said:

Since you do not use the normal configuration (MSP powered by LaunchPad in LaunchPad socket), it is possible that you're haveing problems with the supply voltage and/or your reset pin.

The circuit is powered from the LaunchPad's J6 supply pins and it seems to be fine. The MSP430AFE252 reset pin is pulled up to VCC with a 47k resistor, as usual.

Jens-Michael Gross said:

It is possible that under some circumstances the MSP doesn't start at all (and therefore no interrupts occur).

.

It actually starts. In debugger mode with stepping I can observe the changes in the registers and I can also observe the LED switching on and off at the code lines dealing with  P2OUT (code above)

Jens-Michael Gross said:

To ensure the code is running, you should toggle an LED right at the start of main.

.

Done and it toggles. Only the interrupts are missing.

 

JustGreg said:

Done and it toggles. Only the interrupts are missing.

It looks like the debugger messes with the MSPs default values, so some registers aren't as they are supposed to be. Maybe the EEM is configured in a way that hinders free-running.

It's realyl strange.

Maybe you should post your code for analysis, as this doesn't seem to be a general problem.

It's also possible that there is a racing condition somewhere that works right if ther eis no debugger influence or single-stepping, but not if the debugger attaches and then lets the device go.

Hi Jens,

 

Jens-Michael Gross said:

Maybe the EEM is configured in a way that hinders free-running.

Excuse me but what is EEM?

 

Jens-Michael Gross said:

Maybe you should post your code for analysis, as this doesn't seem to be a general problem.

 

The code is my second post. Or you mean something else?

 

Jens-Michael Gross said:

It's also possible that there is a racing condition somewhere that works right if ther eis no debugger influence or single-stepping, but not if the debugger attaches and then lets the device go.

I tried with LPs with old firmware, LPs with (possibly) upgraded  firmware and also tested my old USB FET which was in my Chronos kit.

 

 

 

JustGreg said:

Excuse me but what is EEM?

Embedded Emulation Module. It can only be programmed directly by JTAG and contains the logic for breakpoints etc. You cannot influence it from code.

JustGreg said:

The code is my second post. Or you mean something else?

When replying, one can only see the post one is replying to. But you're right, that's what I meant.

I don't see anything in your code that might cause the observed behavior.

The only thing I notice is that entering LPM0 and setting GIE is the very last instruction of main. Since the next instruction is fetched before the LPM is active and executed before the ISR is entered, this might be the reason. If, for example, the debugger has set an internal default breakpoint at this place (whether it holds any valid code at all depends on the compiler and its runtime library), this might cause problems, as LPM is active when this location is hit.
(Well, this is just a weird theoretical construct, but I don't know what else could cause what you observe: running without debugger and in single step works, but not free-runnign with debugger attached)

What you can try is to put a NOP() right behind the _BIS_SR... and see what happens.

Hi Jens,

 

Tried your NOP tip with no luck unfortunately. I also soldered a new chip on a Schmartboard with only the vital circuitry (VCCs, GND, TEST, RST), programmed with the same code and got the same results: the debugger doesn't want to enter into the Timer ISR.

I'm using the latest IAR Kickstart version.

It's weird....

 

 

JustGreg said:

It's weird....

Indeed.

I read somewhere that the debugger interferes with the LPMs.

So what you could try is replacing the  BIS_SR(LPM0_Bits | GIE); by

BIS_SR(GIE); while(1);

It does not enter LPM anymore, but then there should not be any possible conflict with any debugger action.

 

Hi Jens,

 

I've changed my code according to your suggestion to no avail.  The circuit is immediately starts working when I disconnect the debugging cable but it won't enter into the ISR handler during debugging. It is annoying since I can't really build any serious projects on this - otherwise very appealing - MCU. Anyway, thank you for keeping my topic alive.

Well, I never used a debugger on an MSP.
While debuggers are nice things for checking the program flow or testing an algorithm (and you simply cannot program in Flex without one, argh!), it is completely useless if you have to deal with realtime events.
And the first projects I had to do on an MSP were to read bitpatterns from an HF receiver and fetch measuring data from an energy meter. Well, in teh time teh debugger needs to step (and it takes me to read what the debugger is showing), gazillions of HF data bits and metering values have passed unnoticed.

So I never even tried to use a debugger and instead edeveloped other means, from high level RS232 debugging output to low-level LED blinking codes or port pin toggles.

And my projects are quite large, some are >32k binary code without any 3rd party libraries.

However, there must be a reason for this. Something in the debugger configuration or such.

Note that the debugger can stop the system clocks independently of their configuration. So it might be that your program runs, but the timer is not counting since its clock is stopped by the debugger. (in single stepping, it is also stopped normally, so your peripherals, especially the timers, don't advance while you are studying the screen)
Of course this lock should be removed when you let go. This might be a bug in the debugger.  Or a configuration thing.
Or the register view update clears the timer IFG bit before the interrupt gets triggered (well, unlikely for the CCR0 interrupt, but happened for people who watched the TAIV register in the debugger). It makes no difference if the debugger reads a register or the CPU. Read is read, with all of its side-effects.

And there are many errata in the various errata sheets regarding debugger usage.

I agree that there is life beyond debuggers and I myself often use those methods you mentioned. However debuggers can be very useful for checking the external chip's registers  (RF transceivers, ADCs,etc.). I like to test my RF communication with 2 IDEs running their debuggers in the same time so I can release and receive the packets with breakpoints.

 

JustGreg said:

However debuggers can be very useful for checking the external chip's registers  (RF transceivers, ADCs,etc.).

Indeed - as long as you are aware of potential side-effects. You'd be surprised how many people are not.

JustGreg said:

I like to test my RF communication with 2 IDEs running their debuggers in the same time so I can release and receive the packets with breakpoints.

I used pushbuttons for this purpose, especially since the other side of the communication was an ATMega, but indeed, for this kind of debugging, a debugger is useful.
The problem is that you need to know when it is useful and when it causes more problems than it solves. Most people starting with MCUs thing th edebugger is the solution for everything. And they are dead wrong.

The first debugger I really used whas SWAT - a console-based cross-debugger which was debugging a separate PC and its OS through a serial connection. THIS was real debugging - I could debug even core system processes, the mouse driver and the event system. Things you simply cannot debug if debugger and target run on the same machine, sharing mouse and keyboard.