Strange program behavior

[FabioPIC]

I developed a program on a 18F458 which shows strange and random problems.
While executing the same loop, the problems can arrive after seconds or after hours.
After a long investigation, this is a list in frequency order:
1- a comparision series result seems to be sometimes wrong,
so the program continues to work but gives wrong results
2- on the LCD display sometimes the cursor become active,
sometimes appears some strange character
3- sometimes the CPU hangs-up in the middle of perfect behavior
4- sometimes the program jump to unreachable points (to arrive to these
points is necessary a complex procedure: end of current loop, keyboard
key to enter to the specific menu.

I compiled with 3.249 (run for days, all of the above happens),
with 4.032 (run for one hour, only 1- happened, this is the more
frequent in any case).

Long time ago I read a post regarding "fuzzy PIC behavior" caused
by specific crystal and HS-PLL mode. In this post the author did say
he always use a series resistor as suggested on the datasheet for
AT-cut crystals.

Two questions: someone has it experienced similar problems?
Where can I find hints and material about that?

Thanks a lot to everyone.
Fabio

[PCM programmer]

Do you have the XINST fuse enabled ? If you do, this could explain
the strange problems when running the code. Change it to NOXINST.

If that isn't the problem, then try these things:

This thread has links to posts on "random reset" problems.
http://www.ccsinfo.com/forum/viewtopic.php?t=27638&start=4

This thread suggests reducing the #opt level:
http://www.ccsinfo.com/forum/viewtopic.php?t=23991

[FabioPIC]

XINST??

#fuses H4,NOOSCSEN,BROWNOUT,BORV45,PUT,NOWDT,
NOLVP,PROTECT,CPD,STVREN,WRT,WRTB,NODEBUG,NOWRTD,WRTC, CPB

[PCM programmer]

I made a mistake. The older 18F chips don't have that fuse. The newer
versions such as 18F4580 have it. It doesn't apply to your PIC.

[Humberto]

You will receive better help posting your code (the gurues are waiting holding the
knife in his teeth).

[Guest]

The program is very complicated (it handles at same time two motors
to rotate a parabolic antenna) and too big to be posted here.

Yes, it has two interrupt: one from timer0 and the other from UART receiver.
Timer0 is used to generate delays and timeouts.
I use 16-bit global counters which are set to the desired valued and are
decremented by the timer0 isr down to 0, then the decrement stops.
When I set or read such a variable I disable fiirst the timer0 interrupt
(rda must remains active), but I'll check again if I do it on ALL places.

Anyway, I tried with a version in which the timer0 interrupt is disabled
and again I see the problem 1-. I'll check if the interrupt is really
ALWAYS disabled.

The motors: could their noise travel on the VCC/GND and to be the
problem source? It could be ... but the problem persist also when:
- the motors are non-PWM powered
- one motor stops abruptly when it is in the middle of its run
and when the other is alse in the middle of
its run or is already stopped since several seconds

More, when I choose the PWM-ramp options (the motors start
and stop with a PWM ramp, but in the middle of their run the PWM
si off) rarely happens the following:
one motor changes speed for one or two small periods (a few seconds
each), like the PWM is back on but in a zone well far away from
the ramp zones.
The only explaination for this phenomenous I think is:
at a given point (random) the calculated position is found to
be in the ramp zone, so the PWM comes back on.
But there is no ramp, the speed is well reduced but constant for
a few seconds, then again to the maximum for others seconds ...

... very complicated to understand ...

I'll check against the interrupt (timer0) enabling and I'll come back
with some new.

Thanks

[FabioPIC]

Back with news.

After timer0 interrupt disabling, the program works perfectly for
about 40 minutes, then one motor stops immediately when the other
motor start, but if I start the motor when the one is already on, the
problem disappears.
It it clear: the motor start induce enough noise to produce program
malfunctioning (not a processor reset but flags and/or registers
corruption).
So I soldered on the VCC/GND pairs PIC pins two 100nF SMD capacitors
and the problem seems to disappear at all.

Note:
- the PIC has already, on the PCB, two 100nF capacitors as close as
possible (two mm) to both VCC/GND pairs pins ... but they
are "common" capacitors as provided by the manufacturer
(he prefer to use through-hole and not well known capacitors).
Each active components has its own 100nF cap as close as possible
to its power/gnd pins, as well as the voltage regulators.
The GND is "diffused" on both top and bottom PCB layers, clearance
is 10 mils, the motor driver and power supply input are as far as possile
away from the processor.
Motors and processor have different rectifier bridge + filter capacitor.


- the system works perfecty if powered at 12V: in fact 7 systems have
been already delivered after days of ininterrupted automated tests
(in one case one complete week!!)

- the problems come out if the system is powered over 13V,
where the motors currents became high enough to produce
such a beatifull effects.

Yesterday a 7-hours ininterrupted test @ 14.8V (to have 12.0V at
the motors terminals) has been completely successfull: 1091 random
antenna orientations in contemporaneous azimuth & elevation axis.

So:
===> use good components, against what the chief want to use to save
money

---- thanks to all