MSP430F5418A: Exiting while loop but interrupts firing properly?

VARAD NITIN GOKHALE

Part Number: MSP430F5418A

Hi all,

I am having a strange issue where it seems that my infinite while loop is not executing properly but ISRs are triggering. I know this because I have a UART trace which dumps variables to a terminal. I increment these variables in infinite loop as well as various ISRs. The ones in ISRs constantly change while the ones in while loop stop after a short duration. I am not using any low power mode. Also, I am getting this problem intermittently and happens only at bootup. If the bootup sequence is complete the code runs fine.

It seems to me that the code is either stuck in some kind of a trap ISR or a default handler. The trap ISR is written in ASM. How do I go about incrementing variables in this trap function so that I can request trace?

Here's the skeleton of my code.

main()
{
    init_hw();
    __bis_SR_register(GIE); 
    while(1)
    {
        /*code/*
    }
}

timer_isr()
{
    code;
}

ADC_isr()
{
    code;
}

UART_isr()
{
    REQUEST_TRACE:
        TRANSMIT VARIABLES THROUGH UART;
}

What are the possibilities by which the code is not executing infinite while loop in main and what is the easiest way to debug without using the debugger?

Thanks!

over 7 years ago

0 Jace H over 7 years ago

TI__Guru 56685 points

Hello Varad,

Some suggestions:

Make your own trap ISR by defining the rest of the possible ISRs for the part. You can then place a breakpoint in this ISR function to see which interrupt is enabled in the register window of CCS.

Use GPIO debugging techniques to see where in your code the last instruction was before it ran into a possible trap or infinite loop. GPIO Debug is toggling a free GPIO or multiple GPIOs in different sections of your code, and looking at the toggles via o-scope or logic analyzer to see what is happening in your code without using the intrusive debugger (or along with).

You may want to think about using LPM0 in your loop for code flow reasons if in your loop you are trying to wait for some flag or event form an ISR.

Be mindful that each timer has two ISR Vectors. One for CCR0 and another for all other timer interrupts. A common mistake is enabling na interrupt for one but using the ISR vector for the other.

0 VARAD NITIN GOKHALE over 7 years ago in reply to Jace H

Prodigy 140 points

Hi Jace,

The CPU being trapped in trap interrupt is just a possibility at the moment. How do I make sure that it is indeed the case? Again, I cannot use a debugger in our system since it is a motor based, noisy system, so I am using UART for tracing(see code skeleton: I am using a special UART packet, when sent to MCU will respond with certain values that help me debug).

I went over the trap interrupt and I saw that the system goes in LPM0 on trap. Would requesting the value of SR register using __get_SR_register() over UART and then checking if it is going in LPM0 work? When I do that, I get a value of 0 for SR register, when it should at least show a value of 8(for GIE, since interrupts are fired just fine). Is the SR register being cleared inside an ISR?

Thanks,
Varad

0 Jace H over 7 years ago in reply to VARAD NITIN GOKHALE

TI__Guru 56685 points

Varad,

Yes, SR is cleared inside ISR. In particular, it disables the GIE bit as you do not want an interrupt when in an interrupt (Nested Interrupts are not good for MSP430). I believe the previous value is saved on the stack somewhere, or it maybe some shadow register backup. This way it can be restored once you exit the ISR.

Doing this w/o debug mode is problematic. Again GPIO debugging is going to be your best bet here to see where you are in your program flow. I would also advice making an ISR for every single available ISR Vector. In each of these ISRs, you could output a unique UART code to see what ISRs get fired. Compare that with the ones you thought were enabled to see if you accidentally enabled an ISR that you are not servicing. You can use a similar technique for seeing where you are in code instead of GPIO toggling, but the exact timing will be delayed. This may be important for debug depending on the issue.

You could still possibly use some features if the debugger however. By placing breakpoints in certain areas of code you don't think you should be at, you can then run the application in "Free Run" mode. This allows the application to run normally, but will still break at the breakpoint you set. This would allow you to see the state of the device at the point of the break . There are some other advanced CCS debugger techniques you can use to that are outlined in the following app note: http://www.ti.com/lit/slaa393

0 Danny F over 7 years ago

Genius 3850 points

"Code;"

That's exactly where your problems are.

**Attention** This is a public forum

MSP low-power microcontrollers

MSP low-power microcontroller forum

MSP430F5418A: Exiting while loop but interrupts firing properly?