|
Post by johngo on Jul 29, 2019 20:54:04 GMT -8
Using a 100217-01-001, I was having problems with petting the dog from my RPi 3 B.
The reset was firing as expected, if I had nothing connected to the input of the watchdog, but in trying to control the input with a GPIO pin from RPi and using wiringPi in a c program, I found that using pinMode([pin], INPUT) didn't seem to set a tri-state condition that satisfied the watchdog timer.
I even tried forcing it to tri-state with the wiringPi function: pullUpDnControl([pin], PUD_OFF), but to no avail.
What did work, was using pullUpDnControl([pin], PUD_UP), which, while it's not a tri-state condition, is probably adequate to raise the input to a high enough level, that makes the watchdog input satisfied that it's not low.
Similarly, using 'gpio mode [pin] tri', was also successful as a valid tri-state condition that the watchdog timer was satisfied with.
|
|
|
Post by SDL on Jul 30, 2019 7:03:15 GMT -8
Connecting to the Grove Connector pins instead will fix both problems. They are buffered and don't require a tri-state between pulses.
BP
|
|
|
Post by johngo on Jul 30, 2019 11:24:57 GMT -8
Ah... yes, I was curious what the Grove connector was for... per your note, I did some digging and found the Grove interface details - thank you!
|
|
|
Post by johngo on Aug 4, 2019 4:31:37 GMT -8
Well... I tried the connections at the Grove connector, but still had difficulty, but eventually got it to work by defining the pin as an input (pinMode (31, INPUT)), setting the pull up resistor (pullUpDnControl (31, PUD_UP)), and then my pet subroutine set the pin as an OUTPUT, took it LOW, then changed it back to an INPUT and did a PUD_UP.
If I just defined the pin as an output and set it HIGH, and took the output LOW periodically, my watchdog would not send a reset on the output when I killed the process, suggesting the pin was being left in a state that satisfied/prevented the watchdog from firing.
According to RPi documentation, the I2C pins are supposed to have a fixed pull-up resistor, but possibly they're only on SDA/SCL, not SD/SC, so I was still a bit surprised I needed to issue the PUD_UP.
Incidentally, I also saw odd behavior if I connected to the unbuffered trigger input for WD1 (I didn't test WD2) - when using the HIGH/LOW values for OUTPUT (as opposed to INPUT/PUD_UP), the DOG1_ARDUINORESET output of the watchdog would mysteriously change from the 1 minute timeout, to a 20 second timeout, which isn't enough time for my RPi to finish resetting, which means it would get stuck in rolling resets.
Anyway, all is working perfectly, now.
|
|
|
Post by SDL on Aug 5, 2019 4:55:01 GMT -8
OK, but boy, I'm not sure how. Post the code and let me look at it.
Are you sure it is working? I'd slow down your watchdog pats to one every 3 minutes and make sure it resets your computer.
BP
|
|