TI MSP430 unwanted interrupt triggering

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
I'm confused with unwanted interrupt triggering in my MSP430F413 code.
The interrupt is the NMI/oscillator fault/flash violation with priority
14 at address 0xFFFC. I've checked the interrupt flags, but NMIIFG,
ACCVIFG, OFIFG aren't the source, they are NOT set or not enabled!

I have to tell you that the code runs on my own developed hardware, so
there's probably something wrong with it. But I'm not able to find any
failure up to now and the rest of implemented functions work well. I
don't get this failure on an Olimex board and on a TI board. But on both
and on my own hardware I noticed, that the OFIFG is set and reset
several times without triggering an interrupt if I single step through
the code.

The interrupt is triggered everytime when I single step over an asm
instruction, that enables the port 1 interrupt. So I would expect that
the port 1 interrupt is triggered instead of that one.

I've checked power source voltage, but there aren't any break-downs.
I've checked reset pin signal, but there is no reset condition.
Reset pin is pulled up with 47k to +Vcc and connected with 47nF to ground.

I don't know where to look for an error any more. Any suggestions?

Thanks!

Andreas


Re: TI MSP430 unwanted interrupt triggering
iT SOUNDS LIKE YOU AREN'T FOLLOWING THE CORRECT oscillator start up
procedures. these are outlined in the Basic Clock Module chapter of the
Family User Guide. There was a note on the RST pin resistor as well it
should be < 30k

Al

Andreas Bellgardt wrote:

Quoted text here. Click to load it


Re: TI MSP430 unwanted interrupt triggering
I've found the failure. It wasn't a hardware problem, but a software
failure in combination with a confusing behavior of the MSPGCC/GDB
Insight debugger:
As I ported my software to the new hardware, I had to change some port
instructions like P2OUT, P2IE.. to Port 1. Unfortunately, I forgot to
change the interrupt vector registration.
Then, as the unregistered interrupt occured, GDB/Insight didn't stop at
and didn't show the interrupt vector of this unregistered port 1 but the
interrupt vector 0xfffc (oscillator fault/NMI/flash violation). So I
looked for this kind of problem or failure.
See the interrupt vectors of my buggy program, there's no interrupt
registered except the reset one. When an unregistered interrupt is
triggered, GDB/Insight should show the <_unexpected_> vector in single
step, but it didn't. After single step over the interrupt enable asm
instruction, it stops at the 0xfffc vector!
I use GNU GDB 5.1.1 and GCC 3.2.2.


0000e03a <_unexpected_>:
e03a:    00 13                 reti    

0000ffe0 <InterruptVectors>:
ffe0:    b8 e8                 interrupt service routine at 0xe03a
ffe2:    3a e0                 interrupt service routine at 0xe03a
ffe4:    3a e0                 interrupt service routine at 0xe03a
ffe6:    3a e0                 interrupt service routine at 0xe03a
ffe8:    fe e3                 interrupt service routine at 0xe03a
ffea:    3a e0                 interrupt service routine at 0xe03a
ffec:    3a e0                 interrupt service routine at 0xe03a
ffee:    3a e0                 interrupt service routine at 0xe03a
fff0:    3a e0                 interrupt service routine at 0xe03a
fff2:    3a e0                 interrupt service routine at 0xe03a
fff4:    3a e0                 interrupt service routine at 0xe03a
fff6:    3a e0                 interrupt service routine at 0xe03a
fff8:    3a e0                 interrupt service routine at 0xe03a
fffa:    3a e0                 interrupt service routine at 0xe03a
fffc:    3a e0                 interrupt service routine at 0xe03a
fffe:    00 e0                 interrupt service routine at 0xe000


Re: TI MSP430 unwanted interrupt triggering
Don't know about the behaviour of specific compilers, and never 'expect'
them to do anything. As a matter of course I prefer to declare all
interrupt vectors and put at least minimal handling there.

Al

Andreas Bellgardt wrote:

Quoted text here. Click to load it


Site Timeline