At 04:39 PM 10/24/97 +0200, you wrote:
>Hello there
>
>I am developing using MPASM and ICEPIC emulator v1.63.20.  I am currently
working on a module to control a motor for endurance testing. The idea is to
run the motor, alternately, in one direction and then in the other, keeping
a count, until the motor fails.
>
>My code works fine for a random number of counts and then the TRISA, TRISB
and TRISC registers get corrupted.  They are corrupted to the same values
every time. I have gone through my code exhaustively but cannot find any
obvious bugs.  Doe anyone know how I can set a break point or trace on a
register value to stop the program execution the moment one of the TRIS
registers changes value.  Everytime I try and set a trace in the ICEPIC
emulator I get a serial port error.  The serial port works fine otherwise.
I see also that ICEPIC can be controlled from within Excel using VBA
modules.  I have played with this but the ICEPIC manual does not give too
much detail about using this feature.
>
>I have thought of running the emulator in animation mode and just watching
the TRIS registers to see when they change but the animation is too slow for
the execution of the program.  The motor has a finite degree of travel and
gets overloaded if the motor is driven after it has reached its full extent
of travel in that particular direction.
>
>If anyone has any ideas or can refer me to more information on debugging
with ICEPIC I would be much ablidged.
>
>Thanks in advance.
>
>Martin McArthur
>
Martin,

The new MPLAB works with the ICEPIC hardware, and has conditional break
points. I haven't worked with it
enough to tell you it will work, but from the docs, it should.

The approach I'd try is to echo the value of the TRIS registers into RAM,
then check the values each time I
pass through a monitor loop in the program (or timing loops, or whereever
you want to monitor the values).
When the TRIS values change, jump to a label, where you've set a breakpoint.
Then it's a matter of moving the
test point around, and setting loop counters, etc, to look for patterns and
clues.

The early PIC literature (with the 5x parts) suggested re-initializing the
TRIS registers periodically. Most of my code runs in a monitoring loop. In
that loop, I always reset the watchdog, and re-initialize the TRIS
registers. This may help you solve the problem (though I'm sure you'd rather
FIND it first!).

Have you put a break at the START point of your code? It's possible that a
glitch is resetting the PIC, and you're starting over. I assume you're
controlling your motor via relay(s) or solonoid(s). Have you put a snubbing
diode on the coils? I've had all kinds of fun with inductive kickback
glitching my system.

Hope this helps. I've been where you are, and it's less than fun.

God luck!
Rob Whitney