Jump to content
Sign in to follow this  
glilly

C2c Bug In Interrupt Handler

Recommended Posts

I am working on a large project using 3 PIC16F777 and 1 PIC16F88 tied together in a custom serial network. From time to time I experience random problems with my serial protocol in the error detection routines. After some lengthy debugging, the problem seemed to be related to referencing global variables in my main program loop. The serial protocol drivers (as well as some analog drivers) are interrupt driven. Here is what I found

 

If I included this in the main loop, errors were generated in the serial protocol.

 

void main(void)

....

....

if(Confirm)

InterCnt++;

....

....

 

When I commented out the variable increment, the errors would not occur.

 

void main(void)

....

....

if(Confirm)

// InterCnt++;

....

....

 

I traced back into the _interrupt_body code and the only thing I could find (based on the documentation supllied by MicroChip) was that the command "clrf STATUS" should be placed directly after the "swapf STATUS, W" command.

 

*** This code causes errors:

_interrupt__code

movwf __int_save_cont_W

swapf __int_save_cont_W, F

swapf STATUS, W

movwf __int_save_cont_STATUS

 

*** This code does not cause errors:

_interrupt__code

movwf __int_save_cont_W

swapf __int_save_cont_W, F

swapf STATUS, W

clrf STATUS

movwf __int_save_cont_STATUS

 

Any verification concerning this would be appreciated.

 

glilly

Share this post


Link to post
Share on other sites

I'm sorry, I didn't include the compiler version etc... in my earlier post.

 

Compiler: C2C-plus compiler version 5.5.1e

IDE: SourceBoost IDE version 5.5.1

OS: Windows XP Home, Windows 2000 Professional

 

The problem indicated above would occur randomly depending on the memory allocation of global variables and the way they are/were referenced during the main program loop. Adding the extra line in the output ASM file (so far) seems to eliminate the problem.

Share this post


Link to post
Share on other sites
...I traced back into the _interrupt_body code and the only thing I could find (based on the documentation supllied by MicroChip) was that the command "clrf STATUS" should be placed directly after the "swapf STATUS, W" command...

 

Can you let me know which Microchip documentation do you refer to?

 

Regards,

Pavel

Share this post


Link to post
Share on other sites
...I traced back into the _interrupt_body code and the only thing I could find (based on the documentation supllied by MicroChip) was that the command "clrf STATUS" should be placed directly after the "swapf STATUS, W" command...

 

Can you let me know which Microchip documentation do you refer to?

 

Regards,

Pavel

 

Absolutely. I'm sorry I haven't done that already.

 

PIC16F7X7 PDF Data Sheet Document http://ww1.microchip.com/downloads/en/DeviceDoc/80177e.pdf

Section: 15.16 "Context Saving During Interrupts"

Example 15-1 Has the line "clrf STATUS" directly after "swapf STATUS, W"

 

I'm not sure what the significance of this is, but it eliminates the problem I'm seeing in every case. I was assuming it had to do something with improper memory paging during an interrupt service (It only happens when I am referencing certain global variables in the main foreground loop).

 

glilly

Share this post


Link to post
Share on other sites

gilly,

 

I traced back into the _interrupt_body code and the only thing I could find (based on the documentation supllied by MicroChip) was that the command "clrf STATUS" should be placed directly after the "swapf STATUS, W" command.

 

The primary function of clearing the status register here is to cause memory bank 0 to be selected.

 

It could be done with:

bcf STATUS, RP0

bcf STATUS, RP1

But this uses one more instruction - using clr STATUS is therefore more efficient.

 

As a side affect of using clr status, all other status flags also get cleared.

 

The only thing I could see that could go wrong is that bank is not correctly set when come variables are referenced in the interrupt routine, by adding the clr STATUS you are fixing this problem.

 

The problem may only occur occassionally because is only a problem if the main execution thread sets the bank to a bank other than 0 and then an interrupt occurs

 

Please send a project demonstrating the problem to support@picant.com

 

Regards

Dave

 

PS: This link doesn't seem to refer to the correct document:

PIC16F7X7 PDF Data Sheet Document http://ww1.microchip.com/downloads/en/DeviceDoc/80177e.pdf

Section: 15.16 "Context Saving During Interrupts"

Example 15-1 Has the line "clrf STATUS" directly after "swapf STATUS, W"

Share this post


Link to post
Share on other sites

Sorry about the incorrect link. Here is the correct one.

http://ww1.microchip.com/downloads/en/DeviceDoc/30498c.pdf

 

I will try to compile an example project that illustrates this problem and send it to you. The existing project is fairly large and is interdependent on four processors chained together using SPI communications.

 

Thank you for your time,

 

glilly

Share this post


Link to post
Share on other sites
Sorry about the incorrect link. Here is the correct one.

http://ww1.microchip.com/downloads/en/DeviceDoc/30498c.pdf

 

I will try to compile an example project that illustrates this problem and send it to you. The existing project is fairly large and is interdependent on four processors chained together using SPI communications.

 

Thank you for your time,

 

glilly

 

Have you considered moving to BoostC. BoostC works much better than C2C in almost all ways.

 

Regards,

Pavel

Share this post


Link to post
Share on other sites
Sorry about the incorrect link. Here is the correct one.

http://ww1.microchip.com/downloads/en/DeviceDoc/30498c.pdf

 

I will try to compile an example project that illustrates this problem and send it to you. The existing project is fairly large and is interdependent on four processors chained together using SPI communications.

 

Thank you for your time,

 

glilly

 

Have you considered moving to BoostC. BoostC works much better than C2C in almost all ways.

 

Regards,

Pavel

 

 

Yes, I have. Actualy, I recently tried compiling in BoostC and recieved quite a few errors. I just haven't had time to go back and weed through the code and make it compliant with BoostC. I will probably make the switch eventually, in the mean time, adding the extra line to the asm file seems to fix the other problem. So, I'm able to work with it.

 

Thank you for your responses.

 

P.S.: In case I failed to mention already, I think your software package is an invaluable tool for PIC programming. I saw your posts regarding interest in helping with the develpement, and I will tell you if I had more time on my hands, I would definetly be interested. I have had experience with other 'C' compilers for other hardware platforms. Great job on the product. It was money well spent.

 

glilly

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...