• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 79 subscribers
  • Views 690 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

CC430 GIE flag (interrupt enable) strange problem

Yourij Bosco
Intellectual 430 points

EM430F6137RF900 toolkit.

IAR for 430 v.5.30.1.

JTAG MSP-FET430UIF.

 

After initialization and some other settings we try to set a GIE flag. The program starts and after setting the flag jumps to 0х10003, non-real address, where it stays.

What it could mean? What could be wrong in the program?

  • 0
    Guru 227245 points

    It usually means that you have an interrupt pending wich tries to execute as soon as you set GIE, but don't have an ISR registered for this interrupt.
    In this case, the interrupt vector still contains 0xffff and causes the CPU to jump to 0xfffe (LSB is ignored and always clear) from where it continues to execute nonsense code.

    If the reset vector content seems to be an instruction with 6 bytes length, the debugger might report 0x10004 as the next address to execute.
    0x10003 is a totally valid address on all MSPs with MSP430X core (20 bit address range). Even if on your MSP there might be no flash (vacant memory).
    On MSPs with non-X core, it would wrap around to 0x0000.

  • 0 in reply to Jens-Michael Gross
    Intellectual 430 points

    Thank you for the answer! It has become more clear what happened.

    But we separated the wheat from the chaff by ourselves: GIE is activated now only there it is really needed. We've founded that GIE and LPM0 mode activation at the same time causes this error.

    For unknown purpose TI included into its sample codes LPM0 mode by default. As the module where GIE is needed functions at the full power all the time so we switched off LPM0 and the issue disappeared.

  • 0 in reply to Yourij Bosco
    Guru 227245 points

    LPM0 deactivates the CPU clock until an interrupt occurs. THen the clock is reactivates to execute the ISR. Once the ISR is finished, teh clock is stopped again, unless the ISR has called the proper macro to exit the LPM. The main thread is frozen until this happens.

    It may be that when teh main thread stands still, there will sooner or later be an interrupt that is unhandled, but that doesn't occur if main is continuing its work.
    However, this means that you have activated this interrupt somehow, as all interrupts are individually disabled on power-up.

    So which IE bits (TAIE, CCRIE, whatever) did you set in your code (only then will an interrupt occur) and which of them is not handled by a properly assigned ISR?

    It is just coincidence that the crash doesn't occur if you remove the LPM0 entry. It might come back at any time when you change something in your code.

**Attention** This is a public forum