[sdcc-devel] [ sdcc-Bugs-1505141 ] Interrupt handler corrupts data

[SourceForge.net <no...@so...>]

Bugs item #1505141, was opened at 2006-06-13 02:49
Message generated for change (Comment added) made by vern98
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100599&aid=1505141&group_id=599

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: pic16 target
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Vern98 (vern98)
Assigned to: Nobody/Anonymous (nobody)
Summary: Interrupt handler corrupts data

Initial Comment:
The source code I'm attaching does the following:
UART_RX_HANDLER
{
   get the character
   put the character in a global linked list
}

Main Loop
while (1)
{
   Refresh_LCD (Displays some global variables, a
heartbeat and characters from the interrupt handler)
   delay();
}

The problem is after I run for awhile (about a minute),
something goes wrong.  I've seen several different things:
1)  My heartbeat go away
2)  My global variables get set to something they
shouldn't.
3)  I get garbage characters displayed (characters I'm
getting from my ISR)

When I am running, the interrupt handler is getting
called very frequently.  (as much as 4 times a milisecond).

My theory of what may be going on is that the ISR is
not properly saving and restoring all the registers it
needs to.  And if the ISR happens to get called at
exactly the wrong time, it ends up corrupting data.

I don't think it is a bug in my code because I ported
the code to the Microchip compiler and it runs fine. 
In my attachment, I also have the source I used for the
Microchip compiler.

I started comparing the assembly between the microchip
compiler and sdcc at the interrupt handler.  They are
quite a bit different, so I gave up and wrote a bug report.

compile command:
sdcc -mpic16 -p18f452 -Wl -m

sdcc version:
sdcc -v
SDCC :
mcs51/gbz80/z80/avr/ds390/pic16/pic14/TININative/xa51/ds400/hc08
2.5.6 #4222 (Jun 12 2006) (MINGW32)

----------------------------------------------------------------------

>Comment By: Vern98 (vern98)
Date: 2006-06-15 02:51

Message:
Logged In: YES 
user_id=1527701

Okay I've stripped down the source as much as I could (see
attached zip file).  In doing so I had to re-define what a
"failure" is.  I use an output pin that goes high when an
interrupt occurs and goes low in the Main Loop.  So when I
get interrupts, I will see the pin toggle.

When I send interrupts in the "broken" code, the line will
toggle for awile and then gets stuck in the On or Off state.

When I send interrupts in the "working" code, the line keeps
toggling forever and doesn't get stuck.

The difference between the "working" and "broken" code is
just a globally defined array.  So I have not idea why the
code is breaking.  Is this possibly an issue with gputils?

----------------------------------------------------------------------

Comment By: Vangelis Rokas (vrokas)
Date: 2006-06-13 23:21

Message:
Logged In: YES 
user_id=770505

Go ahead and remove as much source lines you can.
This will ease the tracing of the assembly listing.

Vangelis


----------------------------------------------------------------------

Comment By: Vern98 (vern98)
Date: 2006-06-13 13:46

Message:
Logged In: YES 
user_id=1527701

If it would be helpful, I can try to reduce the code to a
minimal state that still fails?  

I was thinking about getting rid of all the LCD functions
and just have the ISR grab the byte from the uart and
return.  In the main function I can check the value of a
bunch of global variables that "should" never change.  If
somehting is not what it is supposed to be I can pulse a pin.

----------------------------------------------------------------------

Comment By: Vangelis Rokas (vrokas)
Date: 2006-06-13 12:40

Message:
Logged In: YES 
user_id=770505

Wrong answer. You do use 255 bytes of stack, so this 
shouldn't be a problem normally.

Vangelis


----------------------------------------------------------------------

Comment By: Vangelis Rokas (vrokas)
Date: 2006-06-13 08:49

Message:
Logged In: YES 
user_id=770505

It seems that you are using the default 64 bytes in size 
stack. Consider increasing the stack size with the stack 
pragma and run the program again.

Example:
#pragma stack 0x200 0x100

regards,
Vangelis


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100599&aid=1505141&group_id=599