[CyberArtem]

Hello all
I am building a home made 3 axis cnc router controlled with a custom software written by me. Right now i have 90% finished the router design and working on the electronics , i decided to use pic16f877a as a main controller to which i will connect via 8-bit bus 3 small pic16f84a controllers each of them will control the axis motor with L297+L298 along with two optical interrupters, the communication pic16f877a <=> 3 x pic16f84a is made by a custom commands protocol. I have constructed one "Slave" module for testing and i am sending control packets to it from the "Master" pic. Now the problem i have is that suddenly after a few correct movements the motor starts to rotate rapidly to different directions and don't respond to incoming commands anymore. Even if i disconnect it from the control bus. I think the 'slave' pic is getting 'crazy' somehow, i have tried to pull down the input pins of the pic , tried to add filter capacitors on the VDD lines 5 and 12 volts (for the motor) , nothing helps. I have spent much time trying to figure out whats the problem is but with no luck. Can someone post a working diagram interfacing L297 with PICs. Thanks

[Megahertz]

Is the 16F84A watchdog timer reseting the micro and causing the strange behavior?

[sswitaj]

I'm assuming that you're using the internal PWM registers. Check carefully that you're not accidentally writing garbage to those registers. If you have an ICD, stop the chip and check that the actual register values match what you think should be in there.

A common culprit is a read or write to the same address in another bank, with a mis-set bank select register or access bank bit that accidentally overwrites an sfr.

Gg through your address map, and figure out what's in the other banks at that "same" address and see if you might be trying to change those registers.

Alternately, check that you haven't accidentally defined a working variable to use the same space, an easy mistake with two overlapping cblock definitions.

[Horsedorf]

Also, you might want to make sure your command protocol is robust, such that it checks and detects errors in the data stream and doesn't simply assume anything given to it is a valid command. You might want to have your command parser , whe nit sees an invalid command, have it raise an IO pin and simply spin so that you can see if that it what is going on.
You could have stack corruption. You could have noise on your encoder data lines... the possibilities are rather numerous.

Tricks.

Keep a set of io pins spare that you can attach led's to, or a scope to, and have your code write out to these IO pins constantly so that you can follow where it is in the software. You can also use these to display error conditions such that when you have a section of code processing data that you KNOW should be within a certain range, and find out that it's not, you can raise one of the lines or write a certain value to the data lines. Using one line per error is the best so that you can keep track of multiple errors, using all the lines to encode a value gives you more error codes you can watch for though, however, the rate of error writes to those pins would predicate the need for a logic analyzer or some way to record the changes that go onto them.

Good luck.
Horsedorf

[Megahertz]

I do not believe the PIC16F84A is ICD capably.

[Larken]

The 297/298 can't run away on a stepper motor. It only moves if you send it pulses. SO
The PIC is sending it pulses. Probably your code is stuck in a loop and not exiting.
It takes 1000's of compile-test-fix-recompile steps to get all the bugs out.

Have the step routine output a flag or character when it hits the end of the routine. This way you see if it ever got there and exited.