Page 1 of 1

Conflict between LCD_Start and Interrupt

Posted: Sat Jan 02, 2010 10:54 am
by Eric
Hi team,

I received this strange error during compilation of my program.
snap0372.jpg
(115.74 KiB) Downloaded 1555 times
I stripped down the program until I was able to pinpoint the error exactly ( see attachement )
The program uses 2 interrupts: one TMRO interrupt and one RB1 interrupt.
This worked fine until I added the LCD_Start macro.
From that moment this error appeared.

Any ideas?

Eric

Succesfull 2010.

Re: Conflict between LCD_Start and Interrupt

Posted: Sun Jan 03, 2010 11:19 am
by Steve
I'm guessing you have some lengthy code in the interrupt macros which is causing this warning. There are a lot of posts on this forum about the "correct" way to code with interrupts - the basic rule is to keep the code very short inside the interrupt itself and do any lengthy tasks (e.g. writing to an LCD) in the main loop of your program.

Re: Conflict between LCD_Start and Interrupt

Posted: Sun Jan 03, 2010 10:50 pm
by medelec35
My guess is both LCD start and keypad read, both access the same delay (i.e delay macro which is inbuilt), therefore message about the corruption is displayed. In reality it would probably work fine and is nothing to worry about.

Re: Conflict between LCD_Start and Interrupt

Posted: Tue Jan 05, 2010 11:19 pm
by Eric
Hello Steve,

The length of my 2 interrupt routines are very short. They just set a flag. It is in fact the same routine as shown in the example.
I have the feeling that Medelec is right with his comment. Can you confirm that I can safely ignore this warning?

Regards,

Eric

Re: Conflict between LCD_Start and Interrupt

Posted: Wed Jan 06, 2010 8:53 am
by Steve
Hi Eric,

My definition of "short" is probably different to yours - it needs to be short in time, not necessarily in length. For me, the fact that you are accessing a delay function (even though it is a delay_us one) makes it long.

You can ignore this warning if you want, but I think your program will have the potential to go wrong due to the possible stack corruption issue outlined in the error message. I've just looked at this issue on the SourceBoost forums and they definately say to avoid this warning.

Re: Conflict between LCD_Start and Interrupt

Posted: Wed Jan 06, 2010 11:16 am
by Eric
Sorry Steve, but I think you don't understand my point.

This program is very short, has no delays at all and has 2 very short interrupts.
The first interrupt is a RB1 interrupt which reacts on a keypress. Once triggered, it only looks for the keyvalue.
The second interrupt just sets a flag when the timer overflows.
The point is that when I leave out the lcd-start icon, everything compiles without errors.
The moment I add the lcd-start icon, I receive this error message.
You can see it for yourself if you compile this program with and without the lcd-start icon.
I am afraid this is a bug.

In fact, my complete program is a lot bigger then this example and works just fine, but I cannot use the lcd due to this error.

Can you please reconsider this issue or indicate me another way to handle this problem.

Best regards,

Eric

Re: Conflict between LCD_Start and Interrupt

Posted: Wed Jan 06, 2010 11:34 am
by Steve
Sorry, I was trying to solve this without needing to download your program. I've looked at it now and I can see where the problem lies.

In the Keyboard_Int interrupt routine, you are accessing the GetKeypadNumber macro, which uses the delay_us() function. In the Main macro, the LCD Start macro is used, which also uses this delay_us() function. And this is a problem.

In general, you should try to avoid calling *any* macros or delay functions from within an interrupt routine due to the problem of possible stack corruption. With your program as it is, you might not be able to use keypad macros in any macros except the Keyboard_Int macro.

What I'd suggest is that you use a global "flag" to indicate that the interrupt has been triggered, and then access the keypad macro in the main routine.

Alternatively, you could edit the C code of the GetKeypadNumber routine so that it does not use the delay_us routine - use a loop instead as this is just a small delay to allow the column output to settle before reading the row inputs.

I hope this helps.

Re: Conflict between LCD_Start and Interrupt

Posted: Fri Jan 08, 2010 3:10 pm
by Eric
Steve,

Editing the C code, as you suggested, did the job.
Thx,

Eric