Processor halts : Please help

[cwmaddy]

Another thing to note is, program hangs before even reaching to the points of code suggested where stack overflow might occur.
getProgCodes is subroutine and returns with normal return at all execution instances
same is the case with execute

[Archangel]

Another thing to note is, program hangs before even reaching to the points of code suggested where stack overflow might occur.
getProgCodes is subroutine and returns with normal return at all execution instances
same is the case with execute

Hello cwmaddy, Debugging code is much like killing ants, you may not notice just 1, get a bunch and they start to stand out. Where does the program hang ? I like to hook up a serial lcd on an unused pin and put serout/debug markers in my code to find the last routine executed properly. I remove them when the code executes properly. You have nearly 2300 opportunities for a hang in this code, it is a very large program.

[cwmaddy]

Hello,

Thanks for reply
I agree with you in case of debugging firmware
I have put serout statements in the program . Program jumpts to unknown place/starts printing serouts from another routine, when I repeatedly press the pickup-hangup switch. Otherwise execution is normal

cwmaddy

[Archangel]

Hello,

Thanks for reply
I agree with you in case of debugging firmware
I have put serout statements in the program . Program jumpts to unknown place/starts printing serouts from another routine, when I repeatedly press the pickup-hangup switch. Otherwise execution is normal

cwmaddy

Do you have any sub routines that are called with goto and gosub? What I am thinking: you wrote subroutines with the expectation of return sending program back to the line after gosub, and if you send it with a goto it will run right past the return because there is no location in the stack to return to. Just a thought . . .

[Darrel Taylor]

cwmaddy,

I think your biggest problems are in the Interrupts.

1) You've only created 1 wsave variable. But there should be 1 for each bank of ram, usually at addresses $20,$A0,$120 and $1A0.

The PIC cannot change banks before saving the W reg., because that would change W reg. So it has to be saved in whichever bank is currently selected when the interrupt occurs.

Without the other wsave variables, the ISR will be saving and restoring the wrong values, and could be overwriting other variables that have nothing to do with the ISR.

2) Even worse. You're using Basic language statements inside ASM type interrupts, which will corrupt PBP's system variables and can cause just about anything to happen, including jumping to routines that aren't supposed to be running. It also causes other variables to be overwritten with random values, which just causes more random actions.

If you want to use Basic language statements in your ASM interrupts, the easiest way to do it is ...

DT_INTS - Instant Interrupts
http://www.darreltaylor.com/DT_INTS-14/intro.html

hth,

[cwmaddy]

Hello

Thanks a lot for pointing out the wsave error. I had accidentally deleted it and had some other logic in my mind.Things are more clear now. The error is not appearing for the test points I ran. I still do not understand the problem that interrupts might cause by putting basic statements inside asm . PICBasic takes care of such scenarios isn't it? Some other codes which I have written with such structures work perfectly fine.

Regards,
cwmaddy

[Darrel Taylor]

I still do not understand the problem that interrupts might cause by putting basic statements inside asm . PICBasic takes care of such scenarios isn't it? Some other codes which I have written with such structures work perfectly fine.

Then you've been lucky so far, because NO, PicBasic does NOT take care of such scenarios. That's why there's ON INTERRUPT, which allows basic language statements in an interrupt routine. Unfortunately, it also imposes severe limitations on how the interrupts are handled.

With ASM interrupts, you can get away with basic variable assignments like detTone = 0, or simple addition and subtraction timer1_ofcnt = timer1_ofcnt +1. But anything more complex like ... if timer0 > 240 then timer0 = 1, will need to use PBP's system variables which is a BIG No-No. Essentially, any command that places it's code in the "Library" will have this problem. Most definitely SEROUT will not work, and using those serouts in the ISR for debugging will cause new problems of their own, so you won't be seeing the problems you are trying to debug. And then in the getdtmf routine you've got a FOR loop, an ARRAY operation, and a lot of stuff that's commented out with multiple math terms and shifts and and ...<hr>

PBP sets aside several RAM locations with the variables R0 thru R8, some RR? RM? and T? variables. Most of them are listed in the PBPPIC14.RAM file in your PBP folder.

When a command starts, it copies any parameters to the system variables and calls the library routine to actually accomplish the task. As that command continues to run, those variables will be used to count loops, keeps track of time or different states as needed.

If an interrupt happens, it stops that command in the middle and jumps to the ISR. If in the ISR you now run a basic language statement that uses the library, it will copy it's parameters to the system variables in preparation to run the library routine, which overwrites everything that the command that was interrupted was using. The interrupt itself will work fine. But once it returns from the interrupt, the command that was previously running has no idea where it left off. And since the system variables now have data that was not even meant for that type of command, many different errors are possible, wrong answers, lock-ups, resets, invalid branches.

With DT_INTS that I pointed to previously, it saves the state of PBP's system variables, runs the ISR, then restores the system variables before returning from the ISR. This allows basic language statements to be used in ASM interrupts without corrupting PBP's normal flow.
<br>