Strange interrupt behaviour-no context saving??

Coding and general discussion relating to the compiler

Moderators: David Barker, Jerry Messina

Post Reply
User avatar
RadioT
Registered User
Registered User
Posts: 157
Joined: Tue Nov 27, 2007 12:50 pm
Location: Winnipeg, Canada

Strange interrupt behaviour-no context saving??

Post by RadioT » Tue May 28, 2013 5:17 pm

Hello,

We are debugging a problem in our code, and ran across an unexpected item with regard to context saving in interrupts.

Looking at the code disassembly window in MPLab, there are no assembler directives after the Save() command. I have seen where we had to keep interrupts REALLY simple in the past, maybe this is why??

Here is what we see:

Code: Select all

821:               }      
822:               Interrupt Flash(IPLow)
823:                         Save(FSR0,FSR1,PRODL)
824:               
825:               //   if Ir_TX = false then   
826:                 
827:                       If Net_Avail = 0 Then 
 18250    BC88     BTFSC 0xf88, 0x6, ACCESS
 18252    D005     BRA 0x1825e
828:                           Inc(Net_Avail_Count) 
 18254    010A     MOVLB 0xa
 18256    4BCE     INFSNZ 0xce, F, BANKED
 18258    2BCF     INCF 0xcf, F, BANKED
 1825A    0100     MOVLB 0
 1825C    D023     BRA 0x182a4
Any ideas? We are compiling in MPLab with SF as the language tool. SF is version 2.2.1.2-ICC 1.1.5.7 and MPLab 8.84.

-Tom

Jerry Messina
Swordfish Developer
Posts: 1473
Joined: Fri Jan 30, 2009 6:27 pm
Location: US

Post by Jerry Messina » Tue May 28, 2013 8:41 pm

Are you sure MPLAB isn't lying to you?

You might want to double check the .ASM file. In the low-priority ISR you should at least see it saving the STATUS, WREG, and a few others.

2.2.1.2 is "pretty old", but I don't recall seeing that sort of behavior.

Jerry Messina
Swordfish Developer
Posts: 1473
Joined: Fri Jan 30, 2009 6:27 pm
Location: US

Post by Jerry Messina » Tue May 28, 2013 9:52 pm

Tom-

I just realized what you're probably seeing. Sometimes the Disassembly window isn't in address order, and the context save code looks like it's somewhere else.

Find the low-priority isr jump vector at 0x0018... it'll probably look something like
0018 D002 BRA 0x1e

Follow that branch (to location 0x1e in this example) and you should find the context save code. If you pay close attention to the addresses, you'll see it's actually located right before where MPLAB is telling you the Flash() routine is located.

It must have something to do with the symbols in the COFF file.

User avatar
RadioT
Registered User
Registered User
Posts: 157
Joined: Tue Nov 27, 2007 12:50 pm
Location: Winnipeg, Canada

Post by RadioT » Wed May 29, 2013 11:42 am

ah, yes, there it is.
The code at the interrupt vector says:

Code: Select all

847:                 			 ClrWDT 
848:               		End Asm  //clear watchdog timer  
849:               		Restore    
850:               End Interrupt  
 182E2    0010     RETFIE 0
 182E4    0100     MOVLB 0
 182E6    CFEA     MOVFF 0xfea, 0x758
 182E8    F758     NOP
 182EA    CFE9     MOVFF 0xfe9, 0x757
 182EC    F757     NOP
 182EE    CFE2     MOVFF 0xfe2, 0x75a
 182F0    F75A     NOP
 182F2    CFE1     MOVFF 0xfe1, 0x759
 182F4    F759     NOP
 182F6    CFF3     MOVFF 0xff3, 0x75b
 182F8    F75B     NOP
interesting, it is after the interrupt is complete. I suppose that's right...

I see the addresses in the datasheet shows these as FSR0, FSR1 and PRODL. However, there is also an FSR2 register and it's not being moved. I presume "save" would be able to intelligently place FSR2 somewhere for safekeeping? I can find only two instances of it actually being used anywhere in the code so it does not look like any interrupt routine would "corrupt" it. But that flies in the face of Murphy's Law.....so I suppose I should save it too.

-Tom

Jerry Messina
Swordfish Developer
Posts: 1473
Joined: Fri Jan 30, 2009 6:27 pm
Location: US

Post by Jerry Messina » Wed May 29, 2013 1:16 pm

>>interesting, it is after the interrupt is complete. I suppose that's right...

I think what you're looking at there is actually the context save for the high priority ISR (that's the one pointed to by the vector at 0x0008). The low priority save should be located somewhere before the interrupt routine

>>I presume "save" would be able to intelligently place FSR2 somewhere for safekeeping?

Yes... just add it to the SAVE list. There's very few places where FSR2 is used by the compiler, and from what I remember it's just in the USB library. Normal code just uses FSR0 and FSR1.

>>I see the addresses in the datasheet shows these as FSR0, FSR1 and PRODL

Don't know if this applies, but if you're saving PRODL keep in mind that it's actually a 16-bit register, so you may want to be saving PRODH too.
PROD/PRODL/PRODH are defined as a bytes, so you can either add save(PRODL, PRODH) or define a word register and save that

Code: Select all

dim PRODW as word absolute $0FF3
save(PRODW)

Post Reply