Page 1 of 1

Weird behaviour PIC18F2550

Posted: Wed Apr 14, 2010 8:22 pm
by dbh
Hi,

I'm working on a project in which a robot has to navigate through a maze. I'm writing the program in steps, which went quite well the past weeks. Now the program is getting bigger and bigger and the PIC is beginning to behave weird. I noted that sometimes a piece of code is not being executed, and other times it is. I thought this could be a stack problem (even though the 18F2550 has room for 32 adresses). So I implemented a software stack ( -swcs 6 2 1 ). This didn't solve a lot, so I made the biggest interrupt routine a lot smaller (I brought allmost all of the code to subroutines of 'main'). This solved all stack warnings (except for one, but I think it's not possible to cause problems) I thought the problems were solved, but now I'm having some trouble again and I don't know how to solve it anymore.

In a certain part of the code (macro "bochten"), a few similar routines should be executed in succession. This goes fine for the first couple of routines (the robot turns its wheels from left to right with a servo motor (80Hz), connected to CCP2. The speed of the DC motor is being regulated with CCP1). But the last routine doesn't get executed, although the routine is for 99% the same as the previous routines. Instead the DC motor speeds up at maximum power and doesn't get controlled anymore. The wheels should also turn from left to right again but this also doesn't happen. So it seems like the instruction pointer suddenly jumps out of the program code and doesn't return. I'm using interrupts from Timer0 on 200Hz (don't know why it is 200Hz, I calculated it on 1Khz, but 200Hz is also fine) and interrupts on RB0. Besides I included this assembler code to enable PWM on 80Hz (needed for the servo motor). It can be fount in macro "initialisatie":

MOVLW 11111001
MOVWF _trisc ;RC1-2 =output
MOVLW 0x42
MOVWF _osccon ;internal oscillator; 1MHz
CLRF _ccpr1l,0
BCF _ccp1con,4
BCF _ccp1con,5
MOVLW 0x00C3
MOVWF _pr2
MOVLW 00000110
MOVWF _t2con
MOVLW 00001100
MOVWF _ccp2con ; CCP2 in PWM mode
MOVLW 00001100
MOVWF _ccp1con ; CCP1 in PWM mode

I don't know if the inclusion of this code could introduce problems, but I tested the robot several weeks without any problems like these. Suddenly it starts behaving weird. Can anybody help me out or give me some hints please?

Thanks!

Re: Weird behaviour PIC18F2550

Posted: Thu Apr 15, 2010 8:39 am
by Benj
Hello,

Do you have a multimeter or a scope that you could use on the uC power supply. I had similar problems with my CNC machine and found that is was due to spikes from the motors causing the uC to brown out. Adding a fairly large electrolytic capacitor on the supply rail may help to fix this problem.

If this is not the problem and it is the interrupts then you could investigate this by reducing the frequency of the interrupts or lighting an led when in an interrupt service routine and turning it off right before jumping back. This will let you know where the program is hanging.

I have also had a similar problem on AVR when using too many variables in my program. Eg lots of control variables and a large output data array. The program became unstable and eventually would hang. Reducing the overall variable count made the program run correctly again.

Re: Weird behaviour PIC18F2550

Posted: Thu Apr 15, 2010 11:09 am
by dbh
Thanks,

I indeed had some problems with the power supply in the beginning, since the motors are connected to the same supply. That problem got solved by adding some large electrolytic capacitors (14700uF) and some smaller capacitors (10nF and 100nF). So the power supply should be ok.

I'll try to find the error by lighting some leds or by connecting it to a scope (some frequencies are too high to see on a LED)
Maybe the problem is indeed the amount of variables. I'm using lots of them. Could it also be the length of the macro? The problem always occurs at the same place at the end of a long macro.

Re: Weird behaviour PIC18F2550

Posted: Thu Apr 15, 2010 8:23 pm
by dbh
I overlooked the algorithm again and again and suddenly I saw that a small part was missing.
The routine that detects wheel rotation was not being called. This resulted in an infinite loop in the program and in an increasing motor speed.
So after all it was just an error in my program. But thanks for helping me!