Watchdog reboots the system every 4-5 seconds

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.

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/view


PS: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

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

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.

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.