i was testing a simple polling method (for 8031/51 family). after running for 4-5 hours, it seems to be faulty (just don't work anymore). no interrupt utilization. the code simply like this :

mov p0, #0FFh
mov a, p0
jb acc.7, label1
(next instructions)

the program flow starts with this polling, which is could be lasts for hours to wait until triggered (and jump to next instruction). so, processor spent almost whole time polling port 0. its kind like latched up, if done in hours. latter i change the code to be like this:

mov p0, #0FFh
mov a, p0
jb acc.7, label1
(next instructions)

unfortunately, due to dead line, i tests it just for around 3-4 hours, so it can't be compared.

i know actually this is a bad practice. but, just thinkin that i don't need to do any multitasking here(so i feel its okay, even it hogs cpu time). still confused with uncertain results on latter polling code, i take a look on another one used in x86 processor. meanwhile the system (x86) need to multitask, it uses timer counter interrupt as time base to do the polling. so, every predetermined period of time, the processor poll the port, not every time.

so..., any explanation on what happened to the first one (being latched up?), under the hood? any suggestion?

Posted on 2005-01-21 19:57:02 by dion
First of all. Always use interrupts...lol But if you must pole a device than make the polling operation in to a sub-routine that can be called at will. That way you can perform all duties of the main program and periodically call on your polling process.
Posted on 2005-01-23 11:08:38 by mrgone
It's impossible to diagnose what's wrong with the software without knowing more about the input signal. As it stands, the software assumes at least two things: 1) the triggering signal lasts long enough to be detected, and 2) the input signal is clean before the time of triggering.
Posted on 2005-01-23 16:59:58 by tenkey
actually i am refer to the looping. the input signal is obvious already. just is it possible the loop that lasts for hours could lead into a latching up problem.

Posted on 2005-01-24 03:56:28 by dion
just is it possible the loop that lasts for hours could lead into a latching up problem.

No, you should be able to run such a loop indefinately.

I've got a pair of PIC controlled units that have been running this kind of loop since March 2 2002 with no problems. This is an "until end of life test" for a sensor used in medical applications.

The loop I run is a little more complicated then the one you have (approx 110 instructions if I recall), but the point is the same. It runs and runs and runs...

One fine point is you would want to reset the watchdog timer (if enabled) in such a loop so you don't reset periodically.

In my life test I don't use the watchdog, as I would like to see if the code ever does spiral into never-never land as part of this test. In the production code version I *DO* use the watchdog and reset it every time I run the loop.

Thinking about it a little, most every micro controller program will look like this, repeating its basic task loop over and over and over... unless it does one thing at turn on and then sleeps (such as a start-up one shot timer).

(It took me a while to find my way back here... nice to see the place again!)
Posted on 2005-01-25 09:00:41 by Ernie
after watching the hardware connection more carefully, i guess i've found somethin that could be latching things up. the 8031 or many other microprocessor/controller port usually have active low properties.

so, in normal condition (as it internally pulled up), it is high state. meanwhile, the sensor i used to wait in the loop, is active high. so, most of the time, the port line is forced to low. just feel not right, although there is pull up resistor to limit the sink current. is this true reason for the problem?

thanks, and i am glad too, seeing you around again :)
Posted on 2005-01-25 20:56:54 by dion
There should not be a problem with an active high sensor going into an input that seems more accomodating to an active low sensor.

The pull-up resistor makes the input more accomodating to an active low input, since either an not-sensed (inactive high) or a missing sensor (broken wire fault, ect) both look to the input as not-sensed. Only a solid pulled low detection event changes the pin state.

The active low state can also be driven by an open collector output. This also allows multiple sensors to drive the same input "wired-or" style. Open collector is also at least one transistor less then a push pull output so it may be simpler-cheaper-more reliable.

That being said, it is also acceptable to drive an active high sensor into the input with a pull-up. In this case, the pull-up is redundant as the sensor will also drive the input pin. A missing sensor will be seen as a detection event, but in normal operation (no missing sensor, no transient high signals) it all works; this isn't a problem unless you're designing for "fail-safe" operation.

I'm at a loss to suggest what else might be sending your processor into latch up. One way you might find out what is happening is to use unused IO pins as flags... like one pin to toggle high then low every time you pole the input... then another pin to toggle if drop out of the polling loop... something like that, something you can hang a scope probe onto and trigger on the rare (once in hours?) event.

I hope you have a nice digital scope :-)
Posted on 2005-01-26 15:12:56 by Ernie
i've tried it last time. using a led indicator put somewhere. but at last, i had solved the problem in other way. i put this thread just to question if the practice would just a bit different with theory.

Posted on 2005-01-26 19:45:58 by dion