Code Hang Problem

[mka879]

I am using SIM900 with Portb interrupt on change in a project. The system sends SMS every minute. Also an SMS is sent at each interrupt on change. The system runs fine only if there are less than three IOC between 1 minute interval SMS otherwise the code hangs. The code is given below:

[Ttelmah]

Nobody is going to wade through and solve your programming problems for you.

However one glaring place to look. delay_ms(10) inside an interrupt. Search here for 'why' this is almost certainly the cause (given in particular that there are several 500mSec delays in the external code....).

[mka879]

[PCM programmer]

The usual problem of "interrupts disabled to prevent re-entrancy" is not
the case in your program, because you have two #use delay(20M)
statements. This causes the #int_rb routine to have its own separate
delay_ms() library routines.

You need to find the line of code that's causing the lockup.
If you can't find it by inspection, then try this method:

You can put markers in your main while() loop, such as
putc('1');
putc('2');
putc('3');
etc.
Put a marker at the start of the while() loop, and inside each if() or else
block. Also put a marker inside each while() loop that is inside an if().
In other words, track the program flow. Start your program and let
it run. Give it the external input that causes it to fail. Look at the markers
on your terminal window (eg., TeraTerm). Notice the last marker printed.
That's the block of code where it entered and did not leave.

If a function was called in that block of code, enter more markers inside
that function. Track down the exact line that's causing the problem.

The reason for using markers is to test the code in Release mode.

You are using the hardware UART for SMS messages, so the markers
would have to use a software UART. These means you would have to
use streams in the #use rs232() statements and in your code.

To reduce the time spent sending these marker bytes, you could increase
the baud rate for the soft UART to 115200, or maybe higher if it works.
Since you're running interrupts in your program, you will also have to
add DISABLE_INTS to your #use rs232() statement for the soft UART.
Hence the reason for the higher baud rate.

[mka879]

[asmboy]

yes your delays are a BAD idea - but
i am betting flag[] is being overrun inside the int handler.

nothing limits 'counter' to values less than 80 .........
then trashing check var that follows.

you might well not be getting the data you expect and that makes it worse yet....
also the handling of counter is scary since in your mod_test routine RDA_ISR is still active.

the time domain performance of the whole thing is sketchy IMHO.

it takes some run time to fail since it depends on what comes in data wise.
a gaping code fault

[Ttelmah]

Asmboy is right.

The delay though probably causes the actual problem!....

Think about it. Data at 9600bps, means basically one character per mSec. 10mSec delay inside the int_rb handler is 10mSec, when serial is not being handled. Result up to 8 serial characters lost (2 characters in the hardware).

Then according to what is lost you can then get counter overflowing. Result garbage in memory.....

So:

1) Do the delay by programming an interrupt, exiting immediately, and when this interrupt triggers do your tests. Result no serial data lost, so quite probably the problem vanishes.

2) Add a test to limit counter anyway. Much safer if anything else triggers the same problem.

[mka879]

[Ttelmah]

You don't need to clear your timer interrupt at the end of it's call. Minor, but a wasted instruction.

However, a suggestion.
I've not looked at how 'frequent' your timer tick actually is, but you could approach your debounce two different ways:

First one, is to not have int_rb at all....
If your timer tick is reasonably frequent, then just test the inputs in your timer interrupt. If the port changes, record this, then if it is the same in the _next_ interrupt, process the inputs. If your tick is at any reasonable frequency, this is a much better solution than using int_rb and a delay.
As I said, I suspect the core 'reason' behind your data getting out of sync, so the counter overflows, is the characters being lost in the delay....

Second solution is to use another timer. If you are not using timer1 for instance, then when int_rb occurs, just clear this timer's interrupt, program it with a value that will timeout in (say) 10mSec, enable it's interrupt, and exit.
It doesn't matter if the int_rb then triggers again, it'll just reset the same timer.
Move INT_RDA above the INT_RB, then if both happen at the same time, this interrupt will have priority (or you can use #priority to do the same).
Then when this timer interrupts do your tests, and then disable this timer.

Result in either case, is that the processor is not stuck sitting inside an interrupt handler, and blocking anything else from being handled.

[mka879]