Watchdog timer type issue.

Wolfbrother

Hi all,

I have about as simple a program as it gets. I'm looking at a PIR sensor and when it goes high I turn on a motor on a FDC6324 driver for one sec. What's odd, is every now and then it locks up and keeps running. Stranger still, the program seems to keep running and then the thing finally resets if I move in front of the sensor again. I'm thinking it must be some strange hardware issue, but I wanted to get the code up here and see if someone thinks it's something I am doing in software.

I'm using the application circuit outlined in the app note. R1 is 100K, R2 is 10K and C1 is·1000pF. Pin 5 of the FDC is from the Stamp through a 220 Ohm resistor.

Is there a way I can check if the output has been going longer than the second or so and force it low.

Wolfbrother

I'm just bumping this back up so it doesn't get lost in the bottom. I did a forum search and can't find any useful watchdog timer info for the stamp. Anybody have an idea how I can force the stamp to shut off the FDC 6324.

bill190

Do you want this program to constantly loop?

Do you want to always be able to trigger the sensor, then the motor runs?

Mike Green

Your program is simple and the motor on/off part of your code has no decision points ... once it turns the motor on, it can only turn the motor off a little bit later.

There is no watchdog timer available on the Stamps.

I suspect you have a hardware problem. It may be that electrical noise from the motor is causing the Stamp to reset during the PAUSE when the motor is on. When the program restarts, the I/O pin going to the FDC is put into input mode which is a high impedance and the FDC still sees a high enough voltage so it stays on. One easy solution is to put a LOW 12 statement at the beginning of your program, before the start: to force the I/O pin to the FDC to an off state.

That still doesn't solve the problem of why the program restarts sometimes. You may need a different power arrangement or additional filtering for the motor. It's hard to tell without more information about your whole setup.

Post Edited (Mike Green) : 3/1/2010 6:38:16 PM GMT

Wolfbrother

@Mike Green, Well... I'm still not sure what might be happening. I thought about your suggestion that it was resetting and wrote a little startup LED to tell me the program restarted. It hasn't lit up, except on the first run, like it's supposed to. I thought it might be a hardware issue as well, but now I was a bit silly and several LOW 12s with 50 mS delays between them and it hasn't done anything wrong. The only informations I didn't cover was the DC motor, there are three little 5 volt motors parallel wired. They take almost no current to run, but certainly more than the Stamp outputs, so I went to the driver. I also put the motors on a scope and although they have some noise, it's really noise level and not signal level, so I am not thinking that's it. I could do some motor shielding though, just to be safe.

Just an aside, I have noticed when using the propeller, that serial debug seems to need to be disabled if you don't have it hooked up to the computer, I have a debug statement in here that isn't hooked to anything when it's on the bench, is there a rule about debug for the Basic Stamp? I haven't run into this before, but I am also not seeing any major hardware issue.


@ Bill190, yes I want to infinitely loop and whenever the PIR "sees" something and outputs a "1" to run the motors for a half second.

Mike Green

The DEBUG statement will transmit the information whether there's something on the other end to receive or not. If there's nothing there, it results in a brief pause while the information is transmitted anyway.

Other than some sort of hardware error, there's no way that the program would lock up where the motor would continue to run as you described. I can understand how the PIR sensor could trigger again and the motor restart after a very brief pause, but it wouldn't continue to run.

Wolfbrother

Hi Mike,

I'm going to put a protection diode from the FDC6324 output (pin 3) to the V+ of the motor and see if that makes things ok. I agree it must be some hardware issue. I'm wondering if there's some strange back EMF from the motors holding the output FET in some indeterminate state, the diode should stop that. Strange that the problem seems to behave with the three Low 12s in there though.

I'll post what happens.