TIMER Interrupt problem (msp430f5438 TinyOS)

The new MSPs with 430X core (including the 54xx) have a 20 bit address bus and 20 bit registers. The instructions, however, are backwards compatible to the old 16 bit core. For calls that leave the 16 bit address range, or come from outside, there are new instructions CALLA and RETA which push and pop 20 (32) bit to and from stack for the return address.

With ISRs, however, Ti implemented a(normally) 100% compatible way: the upper 4 bit of the PC are pushed to the stack together with the status register, which has unused bits. This saves one cycle and two bytes stack.

upon return from the ISR, the PC is assembled from these 4 status register bits and the 16 bit return address.

In your case, it seems the status register isn't properly, so upon ISR return a wrong PC is assembled. This mechanism is built into the CPU core and not subject to the compiler-generated instructions. And normally it is transparent. But if you mess with the stack in your ISR, or mix 430 and 430x function calls and returns, you get into trouble.

Jens-Michael is correct, but I have an alternate suggestion: You code jumped off into the weeds, then the timer interrupt fired.

From your stack dump, the return address of 665CA is correct. This is the address that sits on the stack as the return address for your interrupt handler, assembled from the upper 4 bits of SR plus the lower 16 bits of PC. This is reported by your memory dump of the stack at 05BFA at the top of your TimerA interrupt handler. This tells me the problem is not in your interrupt handler; you are already dead, you just don't know it yet.

The real question is: How did 665CA finds its way onto the stack? 665CA is vacant memory, which will always fetch 3FFF (JMP PC, a nop). If you somehow jumped to 665CA, the cpu would sit and spin (firing NMI's, which in your code is stubbed to RETI's) until your timer interrupt fired.

Since 0665CA is invalid memory, the question is how did it find its way onto the stack?

-- Chip

 

You might try writing a stub handler for the NMI and see if your debugger will trigger a breakpoint on it. You might be able to gleen some more information that way.

-- Chip

 

ChipD said:

Since 0665CA is invalid memory, the question is how did it find its way onto the stack?

Good question. Lett me narrow it down further: The TOS is 0A65. How can the upper byte of the saved status register be 65? Only 4 bits are userd for the PC storage, the rest is reserved, so where does the '5' come from (or more exactly the '4', as the '1' is the overflow bit)? I admit, I never checked the stack (I never used a debugger for the MSP), but this is strange. Even if the ISR was indeed called from the middle of the void, Bit 9..11 of the saved status register should be either all 0 or all 1. But maybe i'm on the wrong track and these three bits are always random.
Also, it might be pure coincidence that the MSB of the saved PC and the MSB of the saved SP are both 0x65.

Unfortunately, neither the complete ISR nor the code a 0x065ca (Is there code on this place at all?) has been posted. The assembly dum, not the C source.

There's another possibility: the ISR isn't entered because of an interrupt. It is possible that the ISR is entered because the processor was running wild before (stack overflow? array out of bounds?). Then the values on the stack are neither status register nor return address, but something 'random'.
Besides a stack overflow, this can happen if an interrupt occurs and no ISR is assigned. Then the processor will jump to 0xfffe (since the unoccupied vector points to 0xffff) and run wild, eventually arriving at some code.
Also, it may be that the main funciton ends and the processor simply continues into the next function.
It is up to the compiler to handle these last two cases, but there is no general rule what happens if main ends. MSPGCC assigns all unused vectors to a function the just does a RETI (which may still cause a system halt on newer MSPs as the IRQ remains unhandled), some compilers just leave the vectors pointing to 0xffff. Also, on end of main, some add code that puts the MCU into LPM, others just do nothing and end main, just like any other function, with a RET (which jumps to nowhere since there is no return address on the stack).

Hi guys, thank you very much for your fast reply, I'm attaching the C source, I can also upload the nesC file if you consider it would help.

2781.app.zip

Timer ISR is called just once, and the code is working fine, (with timer dissabled it stays on the infinit loop I set to it), the thing is that when the Interrupt gets called....

 

 

 

the code of 0x065ca should be in the asm attached earlier, but the disassembly shows:

    65c8:       b0 12 34 5c     call    #0x5c34 

    65cc:       49 9b           cmp.b   r11,    r9

    65ce:       03 2c           jc      $+8             ;abs 0x65d6

Chip,

thanks for your reply.

I checked your suggestion, but the code works fine until the interrupt is serviced. I agree with your question, because the only one messing with the stack before 0x5f8c (first line of the ISR) is the uP itself, no matter what i've done before with the SP, the last 4 bytes should be the SR & PC. SR gets corrupt and then as you said, I'm already dead inside the ISR code.

So the thing is that SR is getting corrupt somewhere, the rest of the operation is what it should. Bug CPU18 says something similar, but it's not the actual problem, I can see 3 nibbles repeated, but I wonder if this bug is related in some way.

Upon servicing an interrupt service routine, the program counter (PC) is pushed twice

onto the stack instead of the correct operation where the PC, then the SR registers are

pushed onto the stack. This corrupts the SR and possibly the PC on RETI from the ISR.

1100 lines of assembly listing was tough to look at, 6700 lines of C preprocessor output is even worse! By "C source" Jens meant the 20 lines of code you added to the known working base of TinyOS.

I am going to invoke Occam's Razor on this: This is most likely going to turn out to be a bug in the code you modified or added. It is highly unlikely that the TinyOS code is broken, and extraordinarily unlikely -- nigh on impossible -- that the MSP430 is broken.

I suggest abandoning the post-mortem approach, which can be an endless timesink. Get back to a known working code base (the original, unmodified Blink app), and re-introduce tiny changes until it breaks again. Look for buffer overruns, uninitialized pointers, etc.

-- Chip