Stamp death
Archiver
Posts: 46,084
One nice thing about this list is that others don't usually make the
same going-in assumptions about a problem. So allow me to
respectfully suggest some other possibilities consistent with your
description. Such as...
- Your Stamp's PIC is in fact resetting, but that fact is being
masked by some other hardware stuck in some state
- Your Stamp's PIC is resetting, but a software bug causes it to
appear to be in a coma
- Your Stamp is in brownout due to low power, and staying in
brownout because the power remains inadequate even after asserting
RESET
- Your Stamp is resetting, and then immediately resetting, and then
immediately resetting...
The first thing I'd check is the Stamp's power supply voltage when
the problem is in effect. Maybe one of the SSRs (or an infrequent
combination of multiple SSRs active at once) is dragging the supply
voltage too low.
I'd also add an "I'm alive" feature so you know that the Stamp's
program has begun to execute--something like a DEBUG message of a
5-second LED/piezo activation--anything so long as it's the first
thing your program does and gives you some indication upon power
application and/or reset that the gears are actually turning (or
not).
If you have some means to do so, it would also be nice to know what
the last thing the Stamp did/tried to do was. Maybe latch some
status info or function code into a set of LEDs or something.
Knowing what the Stamp was doing when things went amiss may point you
at the problem.
Nifty application!
Regards,
Steve
same going-in assumptions about a problem. So allow me to
respectfully suggest some other possibilities consistent with your
description. Such as...
- Your Stamp's PIC is in fact resetting, but that fact is being
masked by some other hardware stuck in some state
- Your Stamp's PIC is resetting, but a software bug causes it to
appear to be in a coma
- Your Stamp is in brownout due to low power, and staying in
brownout because the power remains inadequate even after asserting
RESET
- Your Stamp is resetting, and then immediately resetting, and then
immediately resetting...
The first thing I'd check is the Stamp's power supply voltage when
the problem is in effect. Maybe one of the SSRs (or an infrequent
combination of multiple SSRs active at once) is dragging the supply
voltage too low.
I'd also add an "I'm alive" feature so you know that the Stamp's
program has begun to execute--something like a DEBUG message of a
5-second LED/piezo activation--anything so long as it's the first
thing your program does and gives you some indication upon power
application and/or reset that the gears are actually turning (or
not).
If you have some means to do so, it would also be nice to know what
the last thing the Stamp did/tried to do was. Maybe latch some
status info or function code into a set of LEDs or something.
Knowing what the Stamp was doing when things went amiss may point you
at the problem.
Nifty application!
Regards,
Steve
Comments
BS2 Stamp is installed on a Super Carrier and has a LED Terminal
AppMod attached. It is designed to control a hot tub and has
opto-isolated outputs to three AC circuits. Every once in a while the
cpu locks up in a way that refuses to respond to the RESET switch.
Only a cycling of the DC supply will restart the CPU.
I'm pretty familiar with the Microchip 16C57 used in the BS2. I have
been programming them for several years and have never seen a Reset
problem. Additionally a low input on the MCLR- pin (Reset)
basically makes sure the oscillator is running and vectors the cpu to
the highest address in memory. The reset is a very sophisticated
process.
Given the above, what could possibly cause the cpu to not respect the
MCLR pin? Could there be a problem in the Scenix SX18AC program for
the LED Terminal AppMod? Could there be some kind of problem in the
24LC16B SEEPROM (which is externally sequenced)?
I have taken reasonable precautions in the I/O circuits but I guess
that something here is triggering the event. To explain the I/O to the
curious it goes something like this:
1. Two output pins control Crydom ASO241 SSRs. These in turn activate
24VAC circuits of which one is a remote (20-30 inches) Omron relay and
the second is another remote Omron relay and the input of a Crydom
A2425E-10 SSR which controls a 1 HP circulator pump. The 24 VAC
circuit is powered by an external bell transformer.
2. Three I/O pins interface a Maxim ADC chip.
3. One input pin with a 10K pullup sense a remote (20-30 inches)
microswitch that responds to air pressure from a user's rubber bulb.
This circuit overrides the circulator's normal regime.
I have designed a watchdog timer around a 74HCT123 that should protect
a dead cpu but only if the RESET- input is in working condition. I
have not installed this on the target system because of its catatonic
behavior.
I am working on ways to reduce the transients associated with I/O. But
it seems that the crash is most likely associated with a turn-on of
the circulator. You may criticize the use of the A2425E-10 here
because it has a random turn on but a zero-cross turn off. But the
Crydom wizard recommended that model because it is superior to the
A2425E (zero-crossing turn on and turn off) with highly inductive
loads (such as 1HP motors).
Does anyone here have any insight into this phenomena?