• State TI Thinks Resolved
  • Locked Locked
  • Replies 13 replies
  • Answers 1 answer
  • Subscribers 79 subscribers
  • Views 1106 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Compiler/MSP430F6736: __bis_SR_register(GIE) not working

Marius Dumas
Prodigy 180 points
Part Number: MSP430F6736

Tool/software: TI C/C++ Compiler

Hello 

I used a simple piece of code from the libraries MSP430F673X_TA0_02.c

TA0CCTL0 = CCIE; // CCR0 interrupt enabled
TA0CCR0 = 50000;
TA0CTL = TASSEL_2 | MC_1 | TACLR; // SMCLK, upmode, clear TAR

__bis_SR_register(GIE); 

When I run this code using TIv18.1.1.LTS compiler, then the system just dont boot up or anything, i tried __enable_interrupt(); as well but nothing works. 

When I remove __bis_SR_register(GIE);  and __enable_interrupt();  from the code, then the system boots up properly and works, but the interrupt on the timer don't work.

I have one Xtal on XIN and XOUT of 32.768kHz  and I build the project in "debug" mode

Is there something Im missing about this?

  • 0
    Prodigy 180 points
    I have even removed the interrupt routine and all so I know its not the content of the interrupt routine itself which cause the system not to start.
  • 0
    Guru 95495 points
    > TA0CCTL0 = CCIE; // CCR0 interrupt enabled

    What does your ISR look like? Are you using TIMER0_A0_VECTOR?
  • 0 in reply to Bruce McKenney
    Prodigy 180 points
    #pragma vector=TIMER0_A0_VECTOR
    __interrupt void TIMER0_A0_ISR(void)
    {
    gLocID++;
    }

    I only have gLocID++; in to check if it executes but it does not. however I used the debugger and found that the Timer0A is running and the settings took effect. But it the LCD display is dead when __bis_SR_register(GIE) or __bis_SR_register in any form is used
  • 0 in reply to Marius Dumas
    Guru 95495 points
    I don't see any LCD code. How do you know it is the timer that is causing this?
  • 0 in reply to Bruce McKenney
    Prodigy 180 points
    I do not think it is the timer that cause this, it seems to be the presence of anything that looks like "__bis_SR_register" then the display goes dead but timer is running and no interrupt. The lcd code is about 1800 lines so I can't share it all, but basically I use the internal LCD to drive a 7 segment LCD. I had the same issue when I did the ISP so later I just manually read the buffer without interrupts. But I must say it is my first project with MSP430 so im still figuring out the tricks
  • 0 in reply to Marius Dumas
    Prodigy 180 points
    With the debugger I have been watching the registers of the LCD such as LCDCCTL0 which I know should be initialized first before display, but none of those LCD related memory or register values are changing they are all 0, But "__bis_SR_register" being part of the timer initialization is run before the display functions. So I get the idea the code just dont go past that statement, it is as if it all stops at "__bis_SR_register" while the timer which is already started is running in the background. no code after that is executed. This is why I dont get a display.
  • 0 in reply to Marius Dumas
    Guru 95495 points
    When you pause in the debugger, where are you executing? Is it in ISR_fault (or some similar name)?

    Your symptom sounds like there's an enabled interrupt (IE bit) that doesn't have an ISR for it. Until the GIE is set something like that can hide forever. The timer code looks OK (a common mistake is using the wrong timer _VECTOR), so I'm trying to guess what else is in there.
  • 0 in reply to Bruce McKenney
    Prodigy 180 points
    I get $isr_trap.asm48:59$() at isr_trap.asm:49 0x004380
  • 0 in reply to Marius Dumas
    Prodigy 180 points
    in isr_trap.asm it says for the function that
    ;-- default ISR handler if user does not supply
    ;-- simply puts device into lpm0

    so I guess it is an Interrupt issue and then it puts the unit into power saving mode
  • 0 in reply to Marius Dumas
    Guru 95495 points

    That's the one. That's the ISR that's assigned to any interrupt that doesn't have an ISR written for it.

    Unfortunately, there's no easy way to find out what the interrupt was that triggered this, so you'll just have to search for stray IE bit settings. I do think CCIE is OK, though.

    [Edit: It could also be a mis-typed _VECTOR name. Those are at least easily located.]

  • 0 in reply to Bruce McKenney
    Prodigy 180 points
    A-Ha I got it, In my time of flight unit initialization where there are a few interrupts enabled. When I disable that initialization then it all works well. So its not 100% yet but I have a good idea now how to get it going. Thank you so much for the tips, it saved me a lot of frustration.
  • 0 in reply to Bruce McKenney
    TI__Guru 53741 points
    Hi Marius,

    i fully agree with Bruce. It looks like that you have enabled an interrupt without having an interrupt service handler available for that.
    What you can you is to check your peripherals it there is an interrupt enabled by accident.
    If this does not help you may need to write a dummy interrupt handler with trap (while(1);) so that you can see where this is coming from.
    An often made error is from the TimerA and TimerB as they have 2 interrupt vector so that one gets enabled without adding the handler or assigning the wrong vector to the existing handler, e.g. TIMER0_A0_VECTOR <-> TIMER0_A1_VECTOR

    Regards,
    Stefan
  • 0 in reply to Bruce McKenney
    TI__Guru 53741 points
    Hi Marius,

    could you solve the issue or do you have further questions regarding this topic?
    If solved, please select "Resolved" for the post that solved your issue so this thread can be closed out. If you have a different question, please select "Ask a related question" or " Ask a new question".
    Thanks a lot!

    Best regards,
    Stefan

**Attention** This is a public forum