Jump to content
Sign in to follow this  
NDHolmes

Possible Isr Context Saving Bug

Recommended Posts

While looking at why my code was never returning from the interrupt handler, I found the following... I don't believe the way the ISR context-saving assembly saves things off under BoostC for a PIC16F874 will actually work correctly. I could just be a moron today and this is all okay, but I've been staring at this for the better part of an hour, and can't find any possible way it could be working reliably.

 

The saving side:

MOVWF Int1Context
SWAPF PCLATH, W
MOVWF Int1Context+D'1'
BCF PCLATH,3
BCF PCLATH,4
(GOTO interrupt, which continues below)        
SWAPF STATUS, W
MOVWF Int1Context+D'2'
SWAPF FSR, W
MOVWF Int1Context+D'3'
BCF STATUS, RP0
BCF STATUS, RP1

 

Note that on an 874 (and 873), not dealing with STATUS as one of the first things leads to ambiguity as to which of the four banks the variables were placed into. Once RP0 and RP1 are cleared, we have no idea where the context variables went, so restoring them becomes a 50/50 shot in the dark.

 

 

The restore code, for clarity:

(Starts off in bank 0)
SWAPF Int1Context+D'3', W
MOVWF FSR
SWAPF Int1Context+D'2', W
MOVWF STATUS
SWAPF Int1Context+D'1', W
MOVWF PCLATH
SWAPF Int1Context, F
SWAPF Int1Context, W
RETFIE

 

 

For these parts, W would need to be mirrored into all banks (2, since the top two fold over onto the bottom two), but the rest need to be dealt with in such a way that they reside in a known bank for retrieval.

 

My apologies if I've overlooked something and have reported a non-problem, but my code is doing really weird things that I can't explain unless the ISR is really mucking about with these variables.

 

Nathan

Edited by NDHolmes

Share this post


Link to post
Share on other sites

NDHolmes,

 

What you miss is the tiny part of context saving that occurs before we goto the interrupt hanling function.

 

Have a look at the .lst file, locate address 0004 and you will see the status reg being saved before we goto the interrupt function ;)

 

Next, interrupt context saving, this is done using memory that resides in all banks or memory that is available in all banks.

 

Now maybe I detect an error, we don't restore status reg first which means we don't get bank to the bank we save our data in - I think this is the error in the linker :(

 

This will need some further investigation.

Any other thoughts, please post.

 

Regards

Dave

Share this post


Link to post
Share on other sites
Have a look at the .lst file, locate address 0004 and you will see the status reg being saved before we goto the interrupt function :(

 

Here's what my list file looks like around the relevant sections:

ORG 0x00000000
0000  293B 	 GOTO	_startup
ORG 0x00000004
0004  00A3 	 MOVWF Int1Context
0005  0E0A 	 SWAPF PCLATH, W
0006  00A4 	 MOVWF Int1Context+D'1'
0007  118A 	 BCF PCLATH,3
0008  120A 	 BCF PCLATH,4
0009  2942 	 GOTO	interrupt
...(snip)...
0142        interrupt
; { interrupt; function begin
0142  0E03 	 SWAPF STATUS, W
0143  00A5 	 MOVWF Int1Context+D'2'
0144  0E04 	 SWAPF FSR, W
0145  00A6 	 MOVWF Int1Context+D'3'
0146  1283 	 BCF STATUS, RP0
0147  1303 	 BCF STATUS, RP1

 

Since there's a jump in the interrupt handler from the stub to the actual function, the PCLATH save makes sense. However, it doesn't address the problem of the fact the 873 and 874 don't have a truly shared bank. The only really workable solution is to hold working in both banks and status in a known location, usually by holding it in working while clearing the register bits. Then just restore status first and working comes from the right location.

 

 

 

Nathan

Share this post


Link to post
Share on other sites
Have a look at the .lst file, locate address 0004 and you will see the status reg being saved before we goto the interrupt function :(

 

Here's what my list file looks like around the relevant sections:

ORG 0x00000000
0000  293B 	 GOTO	_startup
ORG 0x00000004
0004  00A3 	 MOVWF Int1Context
0005  0E0A 	 SWAPF PCLATH, W
0006  00A4 	 MOVWF Int1Context+D'1'
0007  118A 	 BCF PCLATH,3
0008  120A 	 BCF PCLATH,4
0009  2942 	 GOTO	interrupt
...(snip)...
0142        interrupt
; { interrupt; function begin
0142  0E03 	 SWAPF STATUS, W
0143  00A5 	 MOVWF Int1Context+D'2'
0144  0E04 	 SWAPF FSR, W
0145  00A6 	 MOVWF Int1Context+D'3'
0146  1283 	 BCF STATUS, RP0
0147  1303 	 BCF STATUS, RP1

 

Since there's a jump in the interrupt handler from the stub to the actual function, the PCLATH save makes sense. However, it doesn't address the problem of the fact the 873 and 874 don't have a truly shared bank. The only really workable solution is to hold working in both banks and status in a known location, usually by holding it in working while clearing the register bits. Then just restore status first and working comes from the right location.

 

 

 

Nathan

Share this post


Link to post
Share on other sites

Nathan,

 

So we just need to restore the status register before anything else to fix the problem?

 

BTW: You can change the .asm code manually and compiler under MPLABs if you want to prove it.

 

Regards

Dave

Share this post


Link to post
Share on other sites

Nathan,

 

I think now I see :(

 

Status reg needs to be in known place so it can be restored.

The only way to do this is to save it in multiple places, the any can be used before anything else and then ram bank is restore.

 

Regards

Dave

Share this post


Link to post
Share on other sites

Nathan,

 

I see even clearer now, good old C2C had it sorted with its script files.

 

W reg is saved in a location thats common to all banks, then status can be move safely to W reg. Then bank can be set to a know bank and W (now status) plus all other registers can be store.

 

- Doh.

 

Regards

Dave

Share this post


Link to post
Share on other sites

Everyone,

 

This is now fixed :) (actually was fixed a while back).

 

Regards

Dave

Share this post


Link to post
Share on other sites

Join the conversation

You are posting as a guest. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
Sign in to follow this  

×
×
  • Create New...