|
Post by marcelser on Feb 3, 2018 11:22:48 GMT -8
Hi Support,
I really need your help. I wanted to use the watchdog dual to reset my Raspberry PI. I connected everything with GPIO connectors except for PIN1 of the Grove connector which I connected to VDD (3,3V).
Then I wrote a small python script to pat the dog using your snippet it looks like this:
RESET_WATCHDOG1 = 18
import RPi.GPIO as GPIO
import time
GPIO.setmode(GPIO.BCM) # Broadcom pin-numbering scheme
def resetWatchDog():
GPIO.setup(RESET_WATCHDOG1, GPIO.OUT)
GPIO.output( RESET_WATCHDOG1, False)
time.sleep(0.200)
GPIO.setup(RESET_WATCHDOG1, GPIO.IN)
try:
while True:
resetWatchDog()
time.sleep(15)
except KeyboardInterrupt:
GPIO.cleanup() # clean up GPIO on CTRL+C exit
GPIO.cleanup() # clean up GPIO on normal exit
and a service file
[Unit]
Description=Switchdoc Watchdog Refresh
After=multi-user.target
[Service]
Type=idle
ExecStart=/usr/bin/python /home/pi/switchdoc_watchdog.py
[Install]
WantedBy=multi-user.target
This works for some time but after 1-3 hours the watchdog goes crazy and reboots the system every 4-5 seconds in a loop, it never stops and doesn't allow the system to boot! I also tried out the 2nd watchdog timer on the board connecting pin2 of the grove connector to 3,3V and of course also changing GPIO / Reset connector with no avail. I did various tries all with same result.
What am I doing wrong and how can I get the board to work properly? It really drives me crazy because instead of making the system more stable it becomes unusably after 1-3 hours when the watchdog actually enters it's crazy loop.
An interesting thing I discovered while trying to find the problem is, that when I disconnect the "reset" pin header when the watchdog is in it's continous loop mode and allow the system to boot properly the watchdog stops this insanity when the first "patting the dog" GPIO pulse is sent when the python service starts. I don't know if it helps finding the problem but maybe it helps. But atm the watchdog turns out to be completely unstable with this setup.
Please help.
|
|
|
Post by SDL on Feb 4, 2018 19:32:58 GMT -8
Oh and another thing. I saw this is running at a service. Can you try this just running it in a terminal? BP Duplication of this: Marcelser, Something is hosed up here. 4-5 seconds make no sense. How often do they blink with no patting? Write a program to do this to monitor what is going on. Disconnect the Watchdog from the Pi3 Reset Pin Hook up the pin coming from the WatchDog (that was going tot he Reset Pin) to a GPIO input on your Raspberry Pi. Then write a program that monitors the reset pin all the while periodically patting the dog. See if you can catch the odd situation you are seeing, (since you aren't reseting the Raspberry Pi - this MIGHT be a Pi problem). Another suggestion: Try putting a pullup resistor on Pin 1 and Pin 2 (say 10K or so) up to VDD on the Grove Connector and see if that helps. BP Read more: forum.switchdoc.com/thread/283/documentation-model-connection-watch-dog#ixzz56CWULohJ
|
|
|
Post by marcelser on Feb 5, 2018 0:39:38 GMT -8
If it makes no sense or not, it goes dark for about 2 seconds every 4-5 seconds atm. I can make a video of it if you wish.
With no patting the watchdog led 1 blinks after approx 70 seconds and watchdog led 2 blinks after approx 120 seconds, but both watchdogs show same behaviour. Can it be a problem that I only connected Pin1 or Pin2 of the grove connector to VDD but not both of them because I don't have enough 3,3v Pins on the PI? I could add breadboard of course to check if this is the problem.
As first try I will now stop the service and run the program in a terminal, if it still goes crazy. If that doesn't help I will try to catch the reset pin on a GPIO input.
|
|
|
Post by SDL on Feb 6, 2018 9:30:21 GMT -8
Catching the reset pin on a GPIO is the key to figuring out what is going on.
Pin 1 and 2 on the Grove connector need to be connected to VDD. Behavior depends on which pin you connected. Floating input pins (corrected in the latest version of the WatchDog) do odd things.
BP
|
|
|
Post by marcelser on Feb 6, 2018 12:50:26 GMT -8
Ok, I connected both gpio pins (1+2) to vdd, so one of the watchdogs was now periodically blinking as I don't use it's input or reset pin. Then I started the program in a screen session and it ran for about 8 hours, then again the connected watchdog entered its erratic behavior. I even made a 20 secs video this time. So it's not dependent if it runs as a service or in a terminal. Interestingly it keeps resetting the rpi even though the gpio pins are back to default after first reset. Only a “pat the dog“ signal stops the reset loop. I also don't have a pull up resistor you mention at hand, would have to order one first as I normally don't create my own circuitry. Also I would have to learn first how to create a python program which detects the reset on the pin but even if we would have this program how would that solve the problem? The only thing that comes to my mind is saving the output of “gpio read all“ to a file to check gpio pins and their state. Could you assist with the program? But my much bigger question to switchdoc is: how can the electronics on the board even enter this state ever? I think that would clear things up much more then detecting the reset on the pin don't you think you should investigate there? I uploaded the Video I made here on my google drive: drive.google.com/file/d/1Pn2rvKAERHWowDPKzXK1L0OEU155By8j/viewPS:the above link does not work from the forum itself because the link gets wrapped into some request as url parameter and the server the request goes to is either down or doesn't accept requests from the forum. You have to copy paste the link text. Best regards Marc
|
|
|
Post by SDL on Feb 10, 2018 8:09:18 GMT -8
Can you take a very close picture of the way you have connected up the WatchDog to the Raspberry Pi? And make sure you trace the wires back to the Watchdog board and tell me where they are connected.
I'd like to duplicate the problem. This is completely new to us and I don't see how the watchdog circuitry could do this without some aid from the outside. Something is goofy in the inputs.
BP
|
|
|
Post by marcelser on Feb 13, 2018 23:15:36 GMT -8
Hi SDL,
I meanwhile switch from the python program to a shell based loop, see here:
#!/bin/sh echo "watchdog patting started on" `date` while true do echo "patted the dog at" `date` echo "patted the dog at" `date` >> /home/pi/switchdoc_watchdog.log gpio mode 1 out gpio write 1 0 sleep 0.2 gpio mode 1 in sleep 15 done
This worked perfectly well for 4 days. I then also removed that VDD to the second watchdog and started it as a service and it's running since 2 days.
So it seems that the python snippet you provide to include in programs is definitly a bad idea as python somehow goes crazy after too many incovations of the snippet and does some weirdness on the GPIO Pin. I still don't know what it does exactly that makes the watchdog go crazy but it's fact that it happens.
I will probably submit the python code to some python forums to get clarification but it seems
|
|
|
Post by SDL on Feb 15, 2018 17:36:44 GMT -8
Hmm. I don't think Python is the problem. We have run this on Python for years (literally 1.5 years in one case) and no problem.
You said something that triggers something in the back of my mind though. You said "I then also removed that VDD to the second watchdog and started it as a service and it's running since 2 days."
Where specifically did you have the VDD hooked up?
John
|
|
|
Post by marcelser on Feb 20, 2018 15:30:56 GMT -8
Maybe that text was a bit misleading. All I wanted to say is that I first had both Grover Pins (1+2) pulled to VDD on GPIO Pin1 which also powers the watchdog (by using a breadbord) so both watchdogs started blinking unless you pat them.
I then removed grover pin 2 from VDD and onyl connected Grover Pin1 to GPIO Pin 17 which is also 3,3V volts. This allows me to remove the breadboard as I can connect VDD of the watchdog board to GPIO Pin1 and Grover Pin1 to GPIO 17 (to avoid confusion, these are the physical pin numbers I'm talking about, not something like BCM).
As for python all I can say is that this python program I posted is the only program that triggers this weird watchdog behaviour (you saw the video and you know that it goes totally berserk). I'm no python expert, but using a RPI3 using latest Raspbian Stretch with the python program I posted triggers this weird behaviour. No matter if it's run as a service or in a terminal.
using shell (or to be more precise WiringPi which is installed by default) doesn't trigger this behaviour and meanwhile I wrote a little C++ program that does the job and so far it seems to work just fine. So we have now 2 working solutions (shell + c++) and we have the python solution which goes crazy the question is why.
So either I'm doing something stupid in the python program or GPIO library has an issue in python at least when you run it constantly in a loop doing GPIO.setup/GPIO.output thousands of times in a row.
I mean it's fine if you could use python for 1,5 years but then tell me what's wrong with this python program cause I can't find out as python noob and I'm also sick of putting more time into this issue. I now have the C++ service running and I just hope that it doesn't show any weird behaviour in the coming days cause I'm so sick of putting more time into this. It should have been a no brainer I thought and now I have invested hours and hours and hours into this and also extra money because I had to buy a pack of grover to GPIO cables.
So, you can probably understand that I'm a bit pissed and either you provide a proper python file which works or we leave it like it is. Unless the C++ proves to be unreliable too.
|
|
|
Post by SDL on Feb 21, 2018 15:36:55 GMT -8
No need to get nasty.
I'll tell you that EVERYONES Raspberry Pi system is different. Your Python may not be my Python and my Python is not your Python. The system libraries are different in each version of the Raspberry Pi OS. Every single one.
A better can be had using small computers with tightly engineered software and identical departments, such as a TI solution or a major embedded system providers development board. They tie everything down so this sort of stuff only happens rarely.
My point is that the Raspberry Pi software base is a lot looser and more complicated than the major vendors.
Post your Python program and your exact hookup and we will take a look at it and see if we can duplicate it.
Yes, we have run this board many, many months on multiple systems using Python to pat the board. However, YOUR system doesn't like it. And that is the real question.
One question, do you have the output of the WatchDog board tied to your Raspberry Pi reset pin? Obviously, if you are resetting your Pi all the time, but what I am wondering if the behavior occurs with the Raspberry Pi disconnected under Python.
Just trying to eliminate differences.
Also, have you done update/upgrade on your Raspberry Pi stretch to make sure it is the latest and greatest? If so, tell me when you did that last.
BP
|
|
|
Post by marcelser on Feb 23, 2018 9:12:09 GMT -8
Hi,
My exact hookup is (Watchdog->Raspberry) VDD->Pin 1 (3,3V) GND->Pin 6 (GND) DOG2_TRIGGER->Pin 12 (GPIO 18) Grover Pin 2->Pin 17 (3,3V) DOG2_ARDUINORESET->Reset Pin header on RPi
I've extended the Python Program with logs from the first post so I know when it started failing and how long it worked, latest version is here:
RESET_WATCHDOG1 = 18
import RPi.GPIO as GPIO import time import datetime import logging
GPIO.setmode(GPIO.BCM) # Broadcom pin-numbering scheme
logging.basicConfig(filename='/home/pi/switchdoc_watchdog.log',level=logging.DEBUG,format='%(asctime)s %(message)s',filemode='a') logger = logging.getLogger() logging.info('switchdoc_watchdog service started');
def resetWatchDog(): GPIO.setup(RESET_WATCHDOG1, GPIO.OUT) GPIO.output( RESET_WATCHDOG1, False) time.sleep(0.200) print('gpio value now: ' + str(GPIO.input(RESET_WATCHDOG1))) GPIO.setup(RESET_WATCHDOG1, GPIO.IN) print('gpio value after patting: ' + str(GPIO.input(RESET_WATCHDOG1))) print('patted the dog at ' + str(datetime.datetime.now())) logging.info('patting the god') logger.handlers[0].flush()
try: while True: resetWatchDog() time.sleep(15) except KeyboardInterrupt: GPIO.cleanup() # clean up GPIO on CTRL+C exit GPIO.cleanup() # clean up GPIO on normal exit logging.info('switchdoc_watchdog service stopped')
Actually a good question is if it also happens if I disconnect the Pi, if it also starts behaving weirdly or not.
I first ran into that problem when I started this thread and the system was still Raspbian Jessie. At some point in our discussion I thought maybe an update to Stretch will fix this and I updated to Strech that was about 2 weeks ago but it didn't help, it shows exactly the same behaviour. I could of course do another update but I guess that since 2 weeks the problem hasn't been fixed but I can try.
|
|
|
Post by SDL on Feb 24, 2018 11:54:39 GMT -8
Thanks for the information. Now I can hook it up and try it. It has to wait until Monday, unfortunately as I am out of town at a family event.
Two requests:
1) Hook it up on Dog1. See if the problem still exists (I note that as a difference from the way we have used the board in the past)
2) My thought on the Raspberry Pi reset is trying to eliminate any possible feedback from the Pi (I think this is a really low probability thing, frankly).
Best regards, BP
|
|