Processor halts : Please help

Hello All,

I am trying to build a telephone line interfacing circuit. There are two switches in the circuit(Pick up (PU) and hang up(HU)) I wait to see the line ringing. If during this time pick up switch is pressed, I pick the line. On hang up switch, I go to hang up the line by activating relay.

If I do this repeatedly, my PIC hangs . It sometimes hnags in hangup code section. (Please see attached code) There is no pattern or timing sequence in this hanging. Things come back to normal after 50-60 seconds.

I have used trisb to make portb high. This trisb stops working when I execute hangup. I have to again pull them all high. This was putting the unit in oscillations earlier. This is working by initializing trisb again,but ideally this type of modification is not required. I need to understan if something is wrong in the code.
I am confused. I need to find out the reason and remedy for this problem as it is very important for my unit to be fault tolerent.Please help
Thanks in advance.


cwmaddy

Hello All,

I am trying to build a telephone line interfacing circuit. There are two switches in the circuit(Pick up (PU) and hang up(HU)) I wait to see the line ringing. If during this time pick up switch is pressed, I pick the line. On hang up switch, I go to hang up the line by activating relay.

If I do this repeatedly, my PIC hangs . It sometimes hnags in hangup code section. (Please see attached code) There is no pattern or timing sequence in this hanging. Things come back to normal after 50-60 seconds.

I have used trisb to make portb high. This trisb stops working when I execute hangup. I have to again pull them all high. This was putting the unit in oscillations earlier. This is working by initializing trisb again,but ideally this type of modification is not required. I need to understan if something is wrong in the code.
I am confused. I need to find out the reason and remedy for this problem as it is very important for my unit to be fault tolerent.Please help
Thanks in advance.

There is another thing I noticed while debugging. I was trying to locate exactly where the code hangs and where the control goes. I found that one serout statement is repeated executed and there is no connection from the program to that serout statement.No other statement in the code block of that serout is executed. Will it be stack overflow case? I am using fixed pointers ie goto statements and not gosubs

Please help
cwmaddy

Hi cwmaddy

I've browsed through your code. You code quite well and this will take a little time to understand. However, from your problem descriptions, it looks like you are having some stack related issues. That is why you find the serout repeating without reason. The random hanging also indicates a stack failure. I suggest you check on the nesting levels.

Quote:

---

Originally Posted by Jerson

Hi cwmaddy

I've browsed through your code. You code quite well and this will take a little time to understand. However, from your problem descriptions, it looks like you are having some stack related issues. That is why you find the serout repeating without reason. The random hanging also indicates a stack failure. I suggest you check on the nesting levels.

---

gosub getprogcode no return
gosub error1 no return
gosub execute, if true bypass return
gosub lowrel no return
stack fills up, hang.

Thanks for the replies.I shall try to go through code and correct it as per your suggestions I am sorry for the commented and dead code in the file. I shall try to put cleaner code next time.

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

Quote:

---

Originally Posted by 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

---

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.

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

Quote:

---

Originally Posted by 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

---

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 . . .

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,

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

Quote:

---

Originally Posted by cwmaddy

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>

After reading this explaination, I feel if code that does not use PBP library is placed inside interrupt should work fine isnt it?
Eg statements line freqout, sound, pause, serouts will cause problems
but simple math/ array operations should work . Am I right?
If the code which is placed as BASIC code inside interrupt is getting modified at very selected locations in the program and we make sure the variable accesses are mutually exclusive then also it should not pose any problem.

If i dont want to use wsave1,2,3 , if I store wsave register in access location eg $70 , that should solve the purpose am I right?

I found the thread explaining about banks on the forum which saya the following thing-

"When a particular bank is selected with the RP0 and RP1 bits in the STATUS register, any opcode trying to access that bank is limited to 128 bytes. So, $20, $A0, $120 and $1A0 all point to a location that is 32 bytes into their respective BANK. The Variable declarations wsave1-3 are set that way to reserve the same locations in each bank.

That way you don't need to worry which bank you are in. The "MOVWF W_TEMP" always puts the byte in the correct location, no matter which bank is selected."

If my program is in bank1 and interrupt fires, my registers get stored in bank1.If my interrupt lies in different bank it just jumps to the bank (long jumps) and returns with long jump. It picks up wsave from that bank
If we give different offset of wsave1 and wsave, this interrupt handling should produce incorrect results. Am I right?

Thanks and regards,
cwmaddy