• AVR Freaks

PIC18 ISR uses access RAM locations used by main functions and causing corruption

Author
midihobbyist
New Member
  • Total Posts : 2
  • Reward points : 0
  • Joined: 2016/10/27 01:29:05
  • Location: 0
  • Status: offline
2019/05/17 05:34:41 (permalink)
0

PIC18 ISR uses access RAM locations used by main functions and causing corruption

Hello everyone,
 
I've been reading and benefiting from advice on this forum for ages but never needed to post a query until now.
 
I'm using a PIC18F67J94 and developing code in C within MPLAB IDE v5.15 and XC8 compiler v2.05. I've been developing the code for some time now and generally it's been working well until recently when I came upon an issue with my interrupt service routine causing corruption in the main program. I've scoured this forum and others, and consulted the XC8 manual, looking for an answer to the problem but I can't seem to crack it.
 
The problem seems to be, in a nutshell, that the compiler allocates access RAM locations for temporary variables in the ISR which are also shared with temporary variables in the main functions. So as the program jumps to the ISR and then returns from it, those temporary variables in the main functions are (sometimes) corrupted. It's almost as though the compiler doesn't recognise that the ISR is an interrupt and therefore doesn't try to ring-fence RAM storage for temporary variables away from the rest of the program. However that's not the case - it's clear from the assembly list output that the ISR is recognised and, functionally, the ISR is called at the right times. For information, I'm using in legacy mode (interrupt priorities disabled) and declaring the ISR as "interrupt".
 
Now this has only happened fairly recently so I'm trying to back-track to find out what it is I may have done to cause this problem. I haven't included code here as it's fairly large and I though I'd start by checking principles to see if I have potentially mis-declared something or else made some other type of schoolboy error.
 
So if anyone has a few suggestions of things I might check, it would be much appreciated!
 
Sergio
#1

2 Replies Related Threads

    midihobbyist
    New Member
    • Total Posts : 2
    • Reward points : 0
    • Joined: 2016/10/27 01:29:05
    • Location: 0
    • Status: offline
    Re: PIC18 ISR uses access RAM locations used by main functions and causing corruption 2019/05/24 06:13:06 (permalink)
    +2 (2)
    Hi again,
     
    Slightly surprised that it took a full week for my post to be approved and made live on this forum. But in any case, in that time I've solved the problem. And yes, it was a schoolboy error.
     
    For anyone who is interested, the code was working fine until I added a bootload function. I shifted the main code by adding an offset and then incorporated the bootload code in the lower portion of program memory. The bootloader includes a few functions. In order for the compiler to retain the bootload code and additional functions - which aren't called within the main code (and therefore they appear redundant to the compiler) - I declared the bootload and additional functions as GLOBAL. It compiled fine, but here's the schoolboy error... because the bootload function calls these additional functions, I didn't need to declare them as GLOBAL, only the bootload code. Although it seemed to compile ok, it completely screwed up the compiled data stack for the ISR routine for reasons which are totally beyond my grasp of the compiler/linker.
     
    Anyway, sorted now. 
     
    Sergio
    #2
    mlp
    boots too small
    • Total Posts : 749
    • Reward points : 0
    • Joined: 2012/09/10 15:12:07
    • Location: previously Microchip XC8 team
    • Status: offline
    Re: PIC18 ISR uses access RAM locations used by main functions and causing corruption 2019/05/24 16:00:09 (permalink)
    +3 (3)
    midihobbyist
    For anyone who is interested, the code was working fine until I added a bootload function.

    And again we see the consequence of supplying incomplete information at the start: the problem was caused by something that you neglected to tell us initially, so nobody could possibly have helped you anyway.
     
    Always simplify your code to the smallest complete program that still demonstrates the problem.
    Attach a complete ZIP file of the code so that anybody here can build your code exactly as you do and reproduce the problem.
    Be sure to describe completely what you expect, how you test for it, and what you actually see.
     
    Do not show us (or worse, just describe in prose) that portion of your code that you believe is the cause.
    By definition you do not know where the problem lies.

    Mark (this opinion available for hire)
    #3
    Jump to:
    © 2019 APG vNext Commercial Version 4.5