1. Home
  2. Embedded Programming
  3. TI MSP430 unwanted interrupt triggering

TI MSP430 unwanted interrupt triggering

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

Reply to
Andreas Bellgardt
Loading thread data ...

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:

Reply to
onestone

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 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 : e03a: 00 13 reti

0000ffe0 : 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

Reply to
Andreas Bellgardt

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:

Reply to
onestone

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.