Problem with external interrupts (B0-B2) on 18f452

[mackrackit]

I have not studied the problem but I will put in a couple of things.
1- ON INTERRUPT is not the best for time sensitive operations, ASM types are what you need. This is because ON INTs will not happen instantaneously, they will wait for other things to finish.

2- No matter what type of interrupt you use, you will want to get in and out of the ISR as quick as possible. Set a flag or set a AR while in the ISR and act on that in the main routine.

ASM interrupts are a bit difficult at times so Darrel gave us Instant Ints.
http://www.picbasic.co.uk/forum/show...ant+interrupts

[TDuman]

All of the responses I have received are very much appreciated.
I have gotten past accounting for the pulses, and I have been able to measure time and distance accurately (so it seems) thanks to the help from you all and from the engineers at my client.
We are getting ready to ship the first one, but now I have another problem that has been dogging me intermitently throughout this development project.
The system measures time and revolutions of a pulley that is lowering a device on a cable. The main display (two 7-segment LEDs) shows distance-out on one display bank, and the rate at which it is going out or returning on the other display bank. Whenever the system is reset, it increments an event counter (cast#), and resets the counters and elapsed time to zero. Intermittently, it will reset on it's own. As part of the start-up code it increments the cast# and resets all counters to zero. Since that is what seems to be happening, I conclude that it is actually restarting from the beginning. As an example, I started a test two days ago. It ran for about 10 minutes and reset, then ran for about 5 minutes and reset again. But since then it has been running for about 52 hours without a problem.
I have thought that perhaps this is being triggered from a power problem, so I burned the chip with the "brown-out reset" feature disabled. That seems to improve it somewhat but not eliminate the problem altogether.
I am looking for advice as to what (programming or hardware) would trigger this.

I also have another problem.
The main display, as I mentioned, is a pair of 7-segment LEDs (two banks of four) . But I also have a serial LCD (2 lines of 16 characters) that I use for debugging. The system also transmits logging data to a PC via a comm port. In the code, a variable (DEBUGMODE) is set to either zero of 1 to control which display to use (either the LEDs or the debug display, but not both.
During the current test (and one time in a prior test) the LED display froze (distance and rate not changing), but I could tell that the system was still running from the data coming into the PC, (distance, rate, and elapsed time). The debug mode was set off so there should not have been anything on the debug display. But on a hunch, I connected it while the system was wtill running without interrupting it. Sure enough, it is displaying data as if it is in debug mode (accounting for why the the main LED displays were not updating). I conclude from this that my DEBUGMODE variable somehow got changed. It is set only once at the beginning of the program, and then is only used in IF/THEN statements. So what can cause this to happen? I can program around this problem, but my concern is why is it happening, and what else could be happening that I don't know about?

TDuman

[mackrackit]

The reset problem does sound like a power problem. Could be something nearby creating noise. Dirty ground, other motors, welders...

But it could be a code problem also. You think that if it works correctly once it should work correctly every time. Not always once a project is off the bench.
The display problem sorta points to code. The code not working in the environment.

Show you code and tell about the running environment and we might be able to help you solve it.