Actually, I am fairly sure - but not certain - it will work, and I am a little less sure it will work well enough. I have included a link to a schematic of the design below. "Switch 1" is actually a GPIO output pin from an Arduino, and R5 is actually A Raspberry Pi. The intent is to have the Arduino shut down the RPi when a certain variable is true and turn it back on when the variable is false. The default will be for the RPi to be on until the Arduino's GPIO pin goes high, producing a 3.3V signal at R4, which energizes the X5 Optocoupler's LED and turns off the X4 MOSFET. I have run it in my simulator, and it works there, but there are a couple of catches. The problem is , I am using Micro-Cap 12.2, and it does not have exact matches for all of my components.

In particular, Optocoupler X5 does not have a BJT output. I have a ton of H11F1 Optocouplers (read that: free) which I need to use, and they have symmetrical bilateral silicon photo-detectors as their outputs. Micro-Cap does not have an exact match for this, but I think the FET output Coupler will work just fine to switch the P-Channel X4 MOSFET. If anyone knows of any reason why an H11F1 Optocoupler will not work here, please let me know.

A bit more worrisome is the PC-Channel MOSFET. Micro-Cap does not have an exact match for the PMV28XPEAR MOSFET I need to use. Again, I think it will work, but I am not certain. I tried several different MOSFETs in the simulator, and some perform quite well, with less than 0.1V drop, but others have as much as 0.25V drop in the same situation, which is a bit too much. The PMV28XPEAR has a quite low Rds of around 40 milliohms, but I am not at all sure a somewhat higher Rds is why some of the others I used in the sim are failing. Increasing the value of R5 in the sim did not increase the output voltage. Is anyone out there familiar with the PMV28XPEAR, or know of a very low cost MOSFET that would be guaranteed to work? My cost for the PMV28XPEAR is $0.076 each.

http://siliconventures.net/images/Raspberry%20Pi%20Lighting%20HAT%20switch,jpg.JPG

On 23/12/2023 12:53 am, rhor...@gmail.com wrote:
> Actually, I am fairly sure - but not certain - it will work, and I am a little less sure it will work well enough. I have included a link to a schematic of the design below. "Switch 1" is actually a GPIO output pin from an Arduino, and R5 is actually A Raspberry Pi. The intent is to have the Arduino shut down the RPi when a certain variable is true and turn it back on when the variable is false. The default will be for the RPi to be on until the Arduino's GPIO pin goes high, producing a 3.3V signal at R4, which energizes the X5 Optocoupler's LED and turns off the X4 MOSFET. I have run it in my simulator, and it works there, but there are a couple of catches. The problem is , I am using Micro-Cap 12.2, and it does not have exact matches for all of my components.
>
> In particular, Optocoupler X5 does not have a BJT output. I have a ton of H11F1 Optocouplers (read that: free) which I need to use, and they have symmetrical bilateral silicon photo-detectors as their outputs. Micro-Cap does not have an exact match for this, but I think the FET output Coupler will work just fine to switch the P-Channel X4 MOSFET. If anyone knows of any reason why an H11F1 Optocoupler will not work here, please let me know.
>
> A bit more worrisome is the PC-Channel MOSFET. Micro-Cap does not have an exact match for the PMV28XPEAR MOSFET I need to use. Again, I think it will work, but I am not certain. I tried several different MOSFETs in the simulator, and some perform quite well, with less than 0.1V drop, but others have as much as 0.25V drop in the same situation, which is a bit too much. The PMV28XPEAR has a quite low Rds of around 40 milliohms, but I am not at all sure a somewhat higher Rds is why some of the others I used in the sim are failing. Increasing the value of R5 in the sim did not increase the output voltage. Is anyone out there familiar with the PMV28XPEAR, or know of a very low cost MOSFET that would be guaranteed to work? My cost for the PMV28XPEAR is $0.076 each.
>
> http://siliconventures.net/images/Raspberry%20Pi%20Lighting%20HAT%20switch,jpg.JPG

Do you actually need the opto-isolation? The switch would drive an NPN
transistor into saturation when it closed, or a small N-MOSfet. You'd
need a pull-up resistor to +5V to get the voltage swing you want, but
it's much the same circuit with less to go wrong.

--
Bill Sloman, Sydney

On Fri, 22 Dec 2023 05:53:24 -0800 (PST), "rhor...@gmail.com"
<rhorerles@gmail.com> wrote:

>Actually, I am fairly sure - but not certain - it will work, and I am a little less sure it will work well enough. I have included a link to a schematic of the design below. "Switch 1" is actually a GPIO output pin from an Arduino, and R5 is actually A Raspberry Pi. The intent is to have the Arduino shut down the RPi when a certain variable is true and turn it back on when the variable is false. The default will be for the RPi to be on until the Arduino's GPIO pin goes high, producing a 3.3V signal at R4, which energizes the X5 Optocoupler's LED and turns off the X4 MOSFET. I have run it in my simulator, and it works there, but there are a couple of catches. The problem is , I am using Micro-Cap 12.2, and it does not have exact matches for all of my components.
>
>In particular, Optocoupler X5 does not have a BJT output. I have a ton of H11F1 Optocouplers (read that: free) which I need to use, and they have symmetrical bilateral silicon photo-detectors as their outputs. Micro-Cap does not have an exact match for this, but I think the FET output Coupler will work just fine to switch the P-Channel X4 MOSFET. If anyone knows of any reason why an H11F1 Optocoupler will not work here, please let me know.

Should be OK.

>
>A bit more worrisome is the PC-Channel MOSFET. Micro-Cap does not have an exact match for the PMV28XPEAR MOSFET I need to use. Again, I think it will work, but I am not certain. I tried several different MOSFETs in the simulator, and some perform quite well, with less than 0.1V drop, but others have as much as 0.25V drop in the same situation, which is a bit too much. The PMV28XPEAR has a quite low Rds of around 40 milliohms, but I am not at all sure a somewhat higher Rds is why some of the others I used in the sim are failing. Increasing the value of R5 in the sim did not increase the output voltage. Is anyone out there familiar with the PMV28XPEAR, or know of a very low cost MOSFET that would be guaranteed to work? My cost for the PMV28XPEAR is $0.076 each.
>
>http://siliconventures.net/images/Raspberry%20Pi%20Lighting%20HAT%20switch,jpg.JPG

That has to work. Maybe delete R3. Any low-threshold, low Rds-on pfet
will work.

On 12/22/2023 6:53 AM, rhor...@gmail.com wrote:
> Actually, I am fairly sure - but not certain - it will work, and I am a
> little less sure it will work well enough. I have included a link to a
> schematic of the design below. "Switch 1" is actually a GPIO output pin
> from an Arduino, and R5 is actually A Raspberry Pi. The intent is to have
> the Arduino shut down the RPi when a certain variable is true and turn it
> back on when the variable is false. The default will be for the RPi to be
> on until the Arduino's GPIO pin goes high, producing a 3.3V signal at R4,
> which energizes the X5 Optocoupler's LED and turns off the X4 MOSFET.

*Why* do you want to remove power from the rPi? Are you trying to
*conserve* power? Ensure a "restart from POST"? Deactivate
the rPi regardless of what it may be doing at the time? etc.

If trying to conserve power, have you looked at total power consumption
when the rPi is running vs. held in reset?

If trying to ensure a restart or unconditionally deactivate the
rPi, forcing reset can also do the trick.

Be sure to consider the case where the Arduino is powering *up*
and the GPIO(s) will likely be indeterminate (e.g., external pullup
in input mode -- causing your rPi to be OFF until the Arduino
can successfully start, set the GPIO to output mode AND drive
it low (to enable the rPi).

Also, if the rPi is doing something of value, consider any
synchronization issues that may be part of the Arduino
interaction (e.g., if you just power it on/off, there is
no guarantee it will "remember" particular data values
correctly; memory and I/O cycles will be "abused")

fredag den 22. december 2023 kl. 19.45.55 UTC+1 skrev Don Y:
> On 12/22/2023 6:53 AM, rhor...@gmail.com wrote:
> > Actually, I am fairly sure - but not certain - it will work, and I am a
> > little less sure it will work well enough. I have included a link to a
> > schematic of the design below. "Switch 1" is actually a GPIO output pin
> > from an Arduino, and R5 is actually A Raspberry Pi. The intent is to have
> > the Arduino shut down the RPi when a certain variable is true and turn it
> > back on when the variable is false. The default will be for the RPi to be
> > on until the Arduino's GPIO pin goes high, producing a 3.3V signal at R4,
> > which energizes the X5 Optocoupler's LED and turns off the X4 MOSFET.
> *Why* do you want to remove power from the rPi? Are you trying to
> *conserve* power? Ensure a "restart from POST"? Deactivate
> the rPi regardless of what it may be doing at the time? etc.
>
> If trying to conserve power, have you looked at total power consumption
> when the rPi is running vs. held in reset?
>
> If trying to ensure a restart or unconditionally deactivate the
> rPi, forcing reset can also do the trick.
>
> Be sure to consider the case where the Arduino is powering *up*
> and the GPIO(s) will likely be indeterminate (e.g., external pullup
> in input mode -- causing your rPi to be OFF until the Arduino
> can successfully start, set the GPIO to output mode AND drive
> it low (to enable the rPi).
>
> Also, if the rPi is doing something of value, consider any
> synchronization issues that may be part of the Arduino
> interaction (e.g., if you just power it on/off, there is
> no guarantee it will "remember" particular data values
> correctly; memory and I/O cycles will be "abused")

easy enough with linux on a PI, gpio-shutdown and gpio-poweroff are standard drivers

with a gpio you signal to gpio-shutdown to do a shutdown, gpio-poweroff signals via gpio
that turning off the power is safe

On 12/22/2023 12:08 PM, Lasse Langwadt Christensen wrote:
> fredag den 22. december 2023 kl. 19.45.55 UTC+1 skrev Don Y:
>> On 12/22/2023 6:53 AM, rhor...@gmail.com wrote:
>>> Actually, I am fairly sure - but not certain - it will work, and I am a
>>> little less sure it will work well enough. I have included a link to a
>>> schematic of the design below. "Switch 1" is actually a GPIO output pin
>>> from an Arduino, and R5 is actually A Raspberry Pi. The intent is to have
>>> the Arduino shut down the RPi when a certain variable is true and turn it
>>> back on when the variable is false. The default will be for the RPi to be
>>> on until the Arduino's GPIO pin goes high, producing a 3.3V signal at R4,
>>> which energizes the X5 Optocoupler's LED and turns off the X4 MOSFET.
>> *Why* do you want to remove power from the rPi? Are you trying to
>> *conserve* power? Ensure a "restart from POST"? Deactivate
>> the rPi regardless of what it may be doing at the time? etc.
>>
>> If trying to conserve power, have you looked at total power consumption
>> when the rPi is running vs. held in reset?
>>
>> If trying to ensure a restart or unconditionally deactivate the
>> rPi, forcing reset can also do the trick.
>>
>> Be sure to consider the case where the Arduino is powering *up*
>> and the GPIO(s) will likely be indeterminate (e.g., external pullup
>> in input mode -- causing your rPi to be OFF until the Arduino
>> can successfully start, set the GPIO to output mode AND drive
>> it low (to enable the rPi).
>>
>> Also, if the rPi is doing something of value, consider any
>> synchronization issues that may be part of the Arduino
>> interaction (e.g., if you just power it on/off, there is
>> no guarantee it will "remember" particular data values
>> correctly; memory and I/O cycles will be "abused")
>
> easy enough with linux on a PI, gpio-shutdown and gpio-poweroff are standard drivers
>
> with a gpio you signal to gpio-shutdown to do a shutdown, gpio-poweroff signals via gpio
> that turning off the power is safe

The *Arduino* is the device that is directly controlling the power *to*
the rPi. So, unless there is some other mechanism for the Arduino *tell*
the rPi (not mentioned or shown in schematic) that it is about to pull
the plug on the rPi, the rPi will just find power removed from under it...

fredag den 22. december 2023 kl. 22.20.36 UTC+1 skrev Don Y:
> On 12/22/2023 12:08 PM, Lasse Langwadt Christensen wrote:
> > fredag den 22. december 2023 kl. 19.45.55 UTC+1 skrev Don Y:
> >> On 12/22/2023 6:53 AM, rhor...@gmail.com wrote:
> >>> Actually, I am fairly sure - but not certain - it will work, and I am a
> >>> little less sure it will work well enough. I have included a link to a
> >>> schematic of the design below. "Switch 1" is actually a GPIO output pin
> >>> from an Arduino, and R5 is actually A Raspberry Pi. The intent is to have
> >>> the Arduino shut down the RPi when a certain variable is true and turn it
> >>> back on when the variable is false. The default will be for the RPi to be
> >>> on until the Arduino's GPIO pin goes high, producing a 3.3V signal at R4,
> >>> which energizes the X5 Optocoupler's LED and turns off the X4 MOSFET.
> >> *Why* do you want to remove power from the rPi? Are you trying to
> >> *conserve* power? Ensure a "restart from POST"? Deactivate
> >> the rPi regardless of what it may be doing at the time? etc.
> >>
> >> If trying to conserve power, have you looked at total power consumption
> >> when the rPi is running vs. held in reset?
> >>
> >> If trying to ensure a restart or unconditionally deactivate the
> >> rPi, forcing reset can also do the trick.
> >>
> >> Be sure to consider the case where the Arduino is powering *up*
> >> and the GPIO(s) will likely be indeterminate (e.g., external pullup
> >> in input mode -- causing your rPi to be OFF until the Arduino
> >> can successfully start, set the GPIO to output mode AND drive
> >> it low (to enable the rPi).
> >>
> >> Also, if the rPi is doing something of value, consider any
> >> synchronization issues that may be part of the Arduino
> >> interaction (e.g., if you just power it on/off, there is
> >> no guarantee it will "remember" particular data values
> >> correctly; memory and I/O cycles will be "abused")
> >
> > easy enough with linux on a PI, gpio-shutdown and gpio-poweroff are standard drivers
> >
> > with a gpio you signal to gpio-shutdown to do a shutdown, gpio-poweroff signals via gpio
> > that turning off the power is safe
> The *Arduino* is the device that is directly controlling the power *to*
> the rPi. So, unless there is some other mechanism for the Arduino *tell*
> the rPi (not mentioned or shown in schematic) that it is about to pull
> the plug on the rPi, the rPi will just find power removed from under it...

so you need two gpios and enabling two standard drivers

On 12/22/2023 4:24 PM, Lasse Langwadt Christensen wrote:
> fredag den 22. december 2023 kl. 22.20.36 UTC+1 skrev Don Y:
>> On 12/22/2023 12:08 PM, Lasse Langwadt Christensen wrote:
>>> fredag den 22. december 2023 kl. 19.45.55 UTC+1 skrev Don Y:
>>>> On 12/22/2023 6:53 AM, rhor...@gmail.com wrote:
>>>>> Actually, I am fairly sure - but not certain - it will work, and I am a
>>>>> little less sure it will work well enough. I have included a link to a
>>>>> schematic of the design below. "Switch 1" is actually a GPIO output pin
>>>>> from an Arduino, and R5 is actually A Raspberry Pi. The intent is to have
>>>>> the Arduino shut down the RPi when a certain variable is true and turn it
>>>>> back on when the variable is false. The default will be for the RPi to be
>>>>> on until the Arduino's GPIO pin goes high, producing a 3.3V signal at R4,
>>>>> which energizes the X5 Optocoupler's LED and turns off the X4 MOSFET.
>>>> *Why* do you want to remove power from the rPi? Are you trying to
>>>> *conserve* power? Ensure a "restart from POST"? Deactivate
>>>> the rPi regardless of what it may be doing at the time? etc.
>>>>
>>>> If trying to conserve power, have you looked at total power consumption
>>>> when the rPi is running vs. held in reset?
>>>>
>>>> If trying to ensure a restart or unconditionally deactivate the
>>>> rPi, forcing reset can also do the trick.
>>>>
>>>> Be sure to consider the case where the Arduino is powering *up*
>>>> and the GPIO(s) will likely be indeterminate (e.g., external pullup
>>>> in input mode -- causing your rPi to be OFF until the Arduino
>>>> can successfully start, set the GPIO to output mode AND drive
>>>> it low (to enable the rPi).
>>>>
>>>> Also, if the rPi is doing something of value, consider any
>>>> synchronization issues that may be part of the Arduino
>>>> interaction (e.g., if you just power it on/off, there is
>>>> no guarantee it will "remember" particular data values
>>>> correctly; memory and I/O cycles will be "abused")
>>>
>>> easy enough with linux on a PI, gpio-shutdown and gpio-poweroff are standard drivers
>>>
>>> with a gpio you signal to gpio-shutdown to do a shutdown, gpio-poweroff signals via gpio
>>> that turning off the power is safe
>> The *Arduino* is the device that is directly controlling the power *to*
>> the rPi. So, unless there is some other mechanism for the Arduino *tell*
>> the rPi (not mentioned or shown in schematic) that it is about to pull
>> the plug on the rPi, the rPi will just find power removed from under it...
>
> so you need two gpios and enabling two standard drivers

The point is that you (the OP) has to THINK about whether
or not the rPi can just be "unceremoniously" powered on/off.

On Friday, December 22, 2023 at 8:40:35 AM UTC-6, Bill Sloman wrote:
> > http://siliconventures.net/images/Raspberry%20Pi%20Lighting%20HAT%20switch,jpg.JPG
> Do you actually need the opto-isolation? The switch would drive an NPN
> transistor into saturation when it closed, or a small N-MOSfet. You'd
> need a pull-up resistor to +5V to get the voltage swing you want, but
> it's much the same circuit with less to go wrong.

I thought of using a transistor, but an NPN transistor or N-FET won't work the way I would prefer. I would have to drive the transistor ON in order to turn on the Raspberry Pi, assuming the collector / source is connected to the gate of the power FET. Connecting the emitter / drain to the gate would produce too much voltage loss, which is what I am trying to avoid. Of course, I could do that by using a bias resistor and then shut-down would be accomplished by taking the GPIO pin low. The only problem there is the GPIO pin is likely to be driven low on startup, or if the Arduino has some sort of failure. I could use two transistors, of course, to switch the polarity, but that also increases complexity, and as I said, the Opto-isolators are free. I would like to use them some time, so why not now? Note I am not married to the idea.

On Friday, December 22, 2023 at 9:38:15 AM UTC-6, John Larkin wrote:
> >http://siliconventures.net/images/Raspberry%20Pi%20Lighting%20HAT%20switch,jpg.JPG
> That has to work. Maybe delete R3. Any low-threshold, low Rds-on pfet
> will work.
Well, one would think, but some of the MOSFETs I modeled dropped as much as 0.25 Volts. Others modeled to be less than 0.06 volts. The spec sheet says the threshold of the PMV28XPEA is between -0.6 and -1.3V and the Rds-on at 5A is a max of 50ma (less at cooler temperatures), both of which are pretty low. Of course, I agree with you it SHOULD work, but I am a nervous sort of guy, I guess, when I am not certain of something.

R3 is just a safety measure to make sure nothing spurious triggers the LED. It isn't really necessary, of course, but I habitually provide stray current protection whenever I a dealing with semiconductors. Admittedly, diodes are pretty immune. I have been caught a couple of times when I did not short the base / emitter or gate /source of a transistor. It was amusing watching my flashlight slowly turn on all by itself, I must say.

On Friday, December 22, 2023 at 1:08:52 PM UTC-6, Lasse Langwadt Christensen wrote:
> easy enough with linux on a PI, gpio-shutdown and gpio-poweroff are standard drivers
>
> with a gpio you signal to gpio-shutdown to do a shutdown, gpio-poweroff signals via gpio
> that turning off the power is safe

No, this is a watchdog. It must be separate from the Pi. If the Pi locks up - which happens a lot - then the code is no longer running. In addition, there are states monitored by the Arduino of which the Pi knows nothing.

On Friday, December 22, 2023 at 7:47:26 PM UTC-6, Don Y wrote:
> The point is that you (the OP) has to THINK about whether
> or not the rPi can just be "unceremoniously" powered on/off.
Obviously. Again, this is a watchdog. If the Arduino determines the Pi has locked up, it reboots it. SOP for a watchdog circuit.

On Friday, December 22, 2023 at 11:15:28 AM UTC-6, Fred Bloggs wrote:

> > http://siliconventures.net/images/Raspberry%20Pi%20Lighting%20HAT%20switch,jpg.JPG
> Scrap that archaic and unnecessary power hog opto. Use this instead:
Well, first of all, why would I scrap something I can use and for which I have already paid? Secondly, the opto-coupler only uses a couple of milliamps, at most, and that only if I reduce the size of R4. (Which, actually, I think I will just to be safe.) That is nothing compared to the maximum 5 amperes the circuit has to handle. Finally, the opto-coupler is going to be completely dead more than 99% of the time. It will only be energized for about 10 seconds or so whenever it shuts down the Pi, which more than likely will be less than once a week. That was deliberate. Initially I was going to use anormally-on SPST relay, but they are too large and expensive.
>
> https://www.amazon.com/Chanzon-N-Channel-Bipolar-Junction-Transistor/dp/B083TNW1M1/ref=sr_1_1_sspa?th=1
Yeah, I have some 2N3904 transistors, and a few others. See above.
>
> If 1.8R is representative of the RP circuit, which is nearly 3 Amps, then you have to stay with the PMV28XPEAR, a great part for the application. RDS max is 38mR, making power dissipation 3^2 x 0.038= 350 mW which with a max Rtheta,j-a in standard footprint, makes for .350 x 245 K/W= 83oC junction temperature rise. Tjmax of 175oC means your max operating environment is 175-83= 91oC= 200oF, which should be okay, unless it's under a car hood or something like that. Just don't put it near anything that can be damaged by the heat- like the circuit board.

It's worse than under a car hood, unfortunately. It's outside. In South Texas. (And potentially other very hot places.) In direct sunlight. In an air-tight enclosure. The board has a 12V, high speed fan, and a drive for a Peltier cooler.

On Friday, December 22, 2023 at 12:45:55 PM UTC-6, Don Y wrote:
> *Why* do you want to remove power from the rPi? Are you trying to
> *conserve* power?

No. The entire system may use up to several thousand watts. (On AC line power, of course, not on 5VDC ) The Pi's power use is immaterial.

> Ensure a "restart from POST"?

No

>Deactivate the rPi regardless of what it may be doing at the time? etc.

Yes, although usually it won't be doing anything. It will have suffered a kernel panic, or something. The watchdog removes power for a few seconds and then restorers it. The Arduino will also permanently disable the Pi if the environmental temperature goes too high. A few times last year the temperatures in the case rose to over 70C.

> If trying to conserve power, have you looked at total power consumption
> when the rPi is running vs. held in reset?

No, but the opto-coupler only users a couple of milliamps when energized.

> If trying to ensure a restart or unconditionally deactivate the
> rPi, forcing reset can also do the trick.

How? The kernel has panicked (or something), and the Pi is locked up. Other than removing power, how am I to reset it?

> Be sure to consider the case where the Arduino is powering *up*
> and the GPIO(s) will likely be indeterminate (e.g., external pullup
> in input mode -- causing your rPi to be OFF until the Arduino
> can successfully start, set the GPIO to output mode AND drive
> it low (to enable the rPi).

Yes, of course. That is all part of the startup. The first line in the Arduino code will set up the pim and drive the GPIO low. Obviously, I can't do anything about anything until then. If the Pi's operation is delayed by a few seconds, c'est la vie.
> Also, if the rPi is doing something of value,

When the Pi is locked up, the "value" of its operations are moot. Getting it back online is the only issue at hand. The last time the system locked up, the guy was away, and it took over a week for him to come back and unplug and re-plug the power.

> consider any
> synchronization issues that may be part of the Arduino
> interaction (e.g., if you just power it on/off, there is
> no guarantee it will "remember" particular data values
> correctly; memory and I/O cycles will be "abused")

They are not synchronized. Operation is asynchronous. The Arduino monitors two lines from the Pi. One is toggled continuously by software every few milliseconds. If the toggling stops, the Arduino assumes the Pi has stopped functioning and kills power. The second line is held low by the Pi until it wants to disable the Arduino, presumably because the Pi wants to shut down or perform maintenance. This sends the Arduino into a permamnet loop, insuring it will never kill power. The only way to re-enable the watchdog is to manually restart the Arduino.

Here are pictures of the current board design:
http://siliconventures.net/images/Raspberry%20Pi%20Board%20Top.JPG
http://siliconventures.net/images/Raspberry%20Pi%20Board%20Bottom.JPG

On 12/22/2023 11:13 PM, rhor...@gmail.com wrote:
> On Friday, December 22, 2023 at 7:47:26 PM UTC-6, Don Y wrote:
>> The point is that you (the OP) has to THINK about whether
>> or not the rPi can just be "unceremoniously" powered on/off.
> Obviously. Again, this is a watchdog.

"Again"? I don't see that mentioned in your post.

> If the Arduino determines the Pi has locked up, it reboots it. SOP for a watchdog circuit.

Why does YOUR watchdog need to cycle power instead of
asserting RESET?

How are you sure the Arduino can function well-enough to
be able to detect an *apparently* failed rPi? (are you sure the
rPi can't fail in a manner that the Arduino mistakes as being
operational?) Why is the Arduino circumspect but the rPi, not?
(i.e., perhaps the rPi is a poor choice for the application)

Is the flaw in your hardware? Or, software?

Needing a watchdog is usually a sign of a problem elsewhere
in the design. Especially as a means of indicating that the
watchdog has been active is usually needed for users to
determine that the product has likely failed to perform it's
required duties. Imagine how useful a self-reseting fuse
would be to a user... how would he know that something was wrong
if faults were never made known to him?

On 12/23/2023 12:53 AM, rhor...@gmail.com wrote:
> On Friday, December 22, 2023 at 12:45:55 PM UTC-6, Don Y wrote:
>> *Why* do you want to remove power from the rPi? Are you trying to
>> *conserve* power?
>
> No. The entire system may use up to several thousand watts. (On AC line
> power, of course, not on 5VDC ) The Pi's power use is immaterial.
>
>> Ensure a "restart from POST"?
>
> No
>
>> Deactivate the rPi regardless of what it may be doing at the time? etc.
>
> Yes, although usually it won't be doing anything. It will have suffered a
> kernel panic, or something. The watchdog removes power for a few seconds
> and then restorers it.

A reset is insufficient?

(What you've described is "Ensuring a restart from POST".)

Have you quantified how often this is *expected* to occur? The
distribution of expected failure events?

(average interarrival time of wombats)

And, determined that your remedy will "fix" the problem -- without
it immediately reoccurring? Presumably, the rPi adds value to the
design so one would assume you would want it to be operational
more often than not.

> The Arduino will also permanently disable the Pi if
> the environmental temperature goes too high. A few times last year the
> temperatures in the case rose to over 70C.

Then either figure out how to alter the operating environment
or change the approach to the problem.

Or, as the Arduino seems to be TRUSTED to operate in those
extremes, let *it* do the work of the rPi.

>> If trying to ensure a restart or unconditionally deactivate the rPi,
>> forcing reset can also do the trick.
>
> How? The kernel has panicked (or something), and the Pi is locked up. Other
> than removing power, how am I to reset it?

You haven't indicated WHICH rPi you are using. Try bringing RUN to
ground.

>> Be sure to consider the case where the Arduino is powering *up* and the
>> GPIO(s) will likely be indeterminate (e.g., external pullup in input mode
>> -- causing your rPi to be OFF until the Arduino can successfully start,
>> set the GPIO to output mode AND drive it low (to enable the rPi).
>
> Yes, of course. That is all part of the startup. The first line in the
> Arduino code will set up the pim and drive the GPIO low. Obviously, I can't
> do anything about anything until then. If the Pi's operation is delayed by
> a few seconds, c'est la vie.

You can design it so that the rPi defaults to being off -- in the event
that the Arduino isn't present or powered. Or, on -- whichever case you
choose. Presumably, the rPi talks to "something(s)"... are you
sure it will "behave" when crashed?

Most GPIOs default to inputs until programmed otherwise. Many
have light pullups to ensure that -- as inputs -- they are at
a predictable input level. You can exploit this to ensure the
output is sourcing current (through the internal pullup
potentially augmented with an external discrete) and the Arduino
has to *counter* that action.

[I would assume you would want the rPi to default to OFF as
the Arduino can also crash and fail to *actively* reset the
rPi]

>> Also, if the rPi is doing something of value,
>
> When the Pi is locked up, the "value" of its operations are moot. Getting
> it back online is the only issue at hand. The last time the system locked
> up, the guy was away, and it took over a week for him to come back and
> unplug and re-plug the power.

How do you know it won't lock up AGAIN after the guy *leaves*?
If you don't care about availability, then why worry about
ANY lockups?

>> consider any synchronization issues that may be part of the Arduino
>> interaction (e.g., if you just power it on/off, there is no guarantee it
>> will "remember" particular data values correctly; memory and I/O cycles
>> will be "abused")
>
> They are not synchronized. Operation is asynchronous. The Arduino monitors
> two lines from the Pi. One is toggled continuously by software every few
> milliseconds. If the toggling stops, the Arduino assumes the Pi has stopped
> functioning and kills power. The second line is held low by the Pi until it
> wants to disable the Arduino,

So, the output i guaranteed to sink current even when the rPi is crashed?

> presumably because the Pi wants to shut down
> or perform maintenance. This sends the Arduino into a permamnet loop,
> insuring it will never kill power. The only way to re-enable the watchdog
> is to manually restart the Arduino.

So the Arduino is acting as nothing more than a CPU monitor (?)

> Here are pictures of the current board design:
> http://siliconventures.net/images/Raspberry%20Pi%20Board%20Top.JPG
> http://siliconventures.net/images/Raspberry%20Pi%20Board%20Bottom.JPG

On Saturday, December 23, 2023 at 2:25:21 AM UTC-6, Don Y wrote:
> On 12/22/2023 11:13 PM, rhor...@gmail.com wrote:
> > On Friday, December 22, 2023 at 7:47:26 PM UTC-6, Don Y wrote:
> >> The point is that you (the OP) has to THINK about whether
> >> or not the rPi can just be "unceremoniously" powered on/off.
> > Obviously. Again, this is a watchdog.
> "Again"? I don't see that mentioned in your post.
Not in the original post, no, but in more than one reply above.

> > If the Arduino determines the Pi has locked up, it reboots it. SOP for a watchdog circuit.
> Why does YOUR watchdog need to cycle power instead of
> asserting RESET?

RESET on the PI, in hardware, you mean? AFAIK, there is no such thing. In fact, I am almost certain of it, as it is one of the most requested things for the Pi over the years. I think the new Ri 5 has a reset button, not a pin, but in any case, it is unlikely Pi 5s are going to be used with this any time soon. Watchiing a GPIO pin in software suffers the same frailty as any other software. It is terminated during a kernel panic.

> How are you sure the Arduino can function well-enough to
> be able to detect an *apparently* failed rPi? (are you sure the
> rPi can't fail in a manner that the Arduino mistakes as being
> operational?)

Not 100%, of course. So what? SOMETHING is wrong on the Pi, and rebooting should clear it. If not, then something other than a simple kernel panic is going on, and the system needs to be taken in for maintenance. If this were going into space, then triple-redundancy would be in order, with at a minimum two independent CPUs running the same software. This is a hobbyist platform that needs to come in under $50. What do you expect?

> Why is the Arduino circumspect but the rPi, not?

The two are independent, running completely different software. In addition, the software on the Arduino is vastly less complex. All it does is monitor two GPIO lines for simple, unintelligent pulses and control a third GPIO line. 'A few dozen lines of code, at most. The software on the Pi is comprisedof tens of thousands or perhaps even hundreds of thousands of lines of code dealing with innumerable interrupts and tons of I/O.

> (i.e., perhaps the rPi is a poor choice for the application)

It's not my choice. I didn't write it. It is only supported on the Raspberry Pi and the Beaglebone.

> Is the flaw in your hardware? Or, software?

Who knows? One would suspect the software, since none of my Raspberry Pis running other software3 has exhibited the behavior, and every version of Raspberry Pi I have used has exhibited the behavior. It has gotten better through the years, but still persists in Version 5.5. Version 7.2 is out, and after Christmas I am going to see if it still has the issue, assuming it not to be the hardware, of course. It's not that big of an issue, however. Watchdog timers are nothing new.

> Needing a watchdog is usually a sign of a problem elsewhere
> in the design.

Not so much. Systems that run 24/7 can always encounter issues. Our Nortel OPS cost over $20,000 each, and they had watchdog timers to make sure nothing, not even someone accidentally typing `shutdown -h`, would take the system down "permanently". It is an inexpensive and fairly reliable means of hardening a system.

> Especially as a means of indicating that the
> watchdog has been active is usually needed for users to
> determine that the product has likely failed to perform it's
> required duties.

Not at all. Stuff happens. When it does, the system can, if required make a reasonable effort to handle it. Engineering is never about perfection. It is always about meeting the needs in an economical way. $10 worth of hardware is cheap insurance that will eliminate 90% or more of bothersome issues.

> Imagine how useful a self-reseting fuse
> would be to a user... how would he know that something was wrong
> if faults were never made known to him?

I don't have to imagine. Apparently you are unaware the Raspberry Pi and many, many other products *DO* have PPTC fuses that automatically self-reset.. Mouser has hundreds of thousands of them in stock in more than 3400 different sizes and footprints.

lørdag den 23. december 2023 kl. 12.49.23 UTC+1 skrev rhor...@gmail.com:
> On Saturday, December 23, 2023 at 2:25:21 AM UTC-6, Don Y wrote:
> > On 12/22/2023 11:13 PM, rhor...@gmail.com wrote:
> > > On Friday, December 22, 2023 at 7:47:26 PM UTC-6, Don Y wrote:
> > >> The point is that you (the OP) has to THINK about whether
> > >> or not the rPi can just be "unceremoniously" powered on/off.
> > > Obviously. Again, this is a watchdog.
> > "Again"? I don't see that mentioned in your post.
> Not in the original post, no, but in more than one reply above.
> > > If the Arduino determines the Pi has locked up, it reboots it. SOP for a watchdog circuit.
> > Why does YOUR watchdog need to cycle power instead of
> > asserting RESET?
> RESET on the PI, in hardware, you mean? AFAIK, there is no such thing. In fact, I am almost certain of it, as it is one of the most requested things for the Pi over the years.

run_pg is reset, global_en controls the powersupply chip

On a sunny day (Fri, 22 Dec 2023 22:08:50 -0800 (PST)) it happened
"rhor...@gmail.com" <rhorerles@gmail.com> wrote in
<12a3578e-2b70-49f3-b5d3-0d0cb2f5f287n@googlegroups.com>:

>On Friday, December 22, 2023 at 1:08:52 PM UTC-6, Lasse Langwadt Ch=
>ristensen wrote:
>> easy enough with linux on a PI, gpio-shutdown and gpio-poweroff are stand=
>ard drivers
>>
>> with a gpio you signal to gpio-shutdown to do a shutdown, gpio-poweroff s=
>ignals via gpio
>> that turning off the power is safe
>
>No, this is a watchdog. It must be separate from the Pi. If the Pi locks =
>up - which happens a lot -

Pis do not normally lock up, I am posting this from a Pi4 8GB
raspberrypi: ~ # uptime
13:17:17 up 103 days, 20:53, 13 users, load average: 1.37, 1.25, 0.72

It is online, posting this from it, runs many applications, a.o. firefox webbrowser,
music players, drives LED strips, what not..
using it to write C code and compile and test it
Has a 4 TB harddisk connected to it too,
There must be something wrong with your code or hardware.
I have older Pis that had even longer uptimes, like almost a year until I had to disconnect it when I moved house...
But.. all run from an UPS.
Mains dips will kill a Pi, maybe that is it?
There is also an IR camera module hanging from the GPIO on this one.

On Saturday, December 23, 2023 at 6:26:40 AM UTC-6, Lasse Langwadt Christensen wrote:
> > RESET on the PI, in hardware, you mean? AFAIK, there is no such thing. In fact, I am almost certain of it, as it is one of the most requested things for the Pi over the years.
> run_pg is reset, global_en controls the powersupply chip
I think you are talking about a Pico, not a model A, B, or Zero. I don't see either of those here:
https://www.jameco.com/Jameco/workshop/CircuitNotes/raspberry_pi_circuit_note_fig2a.jpg

lørdag den 23. december 2023 kl. 14.03.40 UTC+1 skrev rhor...@gmail.com:
> On Saturday, December 23, 2023 at 2:47:59 AM UTC-6, Don Y wrote:
>
> > A reset is insufficient?
>
> Again, via what means? Telekenesis?
> > (What you've described is "Ensuring a restart from POST".)
> Well, OK. I don't care whether the Pi reboots from POST or from a saved image, as long as any issues are cleared.
> > Have you quantified how often this is *expected* to occur? The
> > distribution of expected failure events?
> To you? No. The systems in question in past years failed once a week or sometimes more. Now they fail once every month or two. Some less, some more often? hey fail invariably if certain attached equipment loses power.
> > And, determined that your remedy will "fix" the problem -- without
> > it immediately reoccurring?
> No. Again, so what? In fact, I know it *WILL* sometimes automatically recur. Occasionally the power has needed to be shut down twice or one a couple of occasions twice before the Pi recovers. The Arduino will take care of that. In teh past, it was not unusual for the micro-SD card to become corrupted when the Pi shuts down. When that happens, the system is tost anyway until a new SD card is inserted. About 2 releases ago, they seem to have fixed that issue, but if it hapens again, it happens. Nothing can automatically fix that in this arena.
> > Presumably, the rPi adds value to the
> > design so one would assume you would want it to be operational
> > more often than not.
> That is an understatement. Many people run these systems entirely on a single Pi, and even those who use multiple Pis have a single master that runs all the rest. When that is down, the entire system fails. Most people at this point just put up with it, and go outside and unplkug the Pi and plug it back in. Some shut off the Pi during the day, and restart it every night. That mostly eliminates the issue for them, but many, like me, run 24/7.
> > > The Arduino will also permanently disable the Pi if
> > > the environmental temperature goes too high. A few times last year the
> > > temperatures in the case rose to over 70C.
> > Then either figure out how to alter the operating environment
> > or change the approach to the problem.
> At this point, I am almost compelled to ask you, "Who died and made you Pope? I will handle it the way I choose, thank you. In particular, this board supports a high speed fan and a Peltier cooler or other 12V, 5A cooling system. Tht has not been the most common issue, however, and in any case has nothing to do woith my original question. I thank you for your input, but I have already taken care of the other issues in a reasonable fashion.
> > Or, as the Arduino seems to be TRUSTED to operate in those
> > extremes, let *it* do the work of the rPi.
> It won't. It can't. Not even close. The software takes up at a bare minimum 4 Gigabytes. Some deployments take more. It runs poorly on a single CPU, if at all in some cases. Sixteen Gigs of storage minimum is suggested and at least 512M of RAM. The Arduino I am using has a total of less than 50 Kilobytes of RAM total, and no external storage. It also has no Wifi and no Ethernet, and both are required, as well as multiple USB ports. It's amazing that a $35 SBC canhandle this much, but a $4 MCO won't, and that is no surprise.
> > >> If trying to ensure a restart or unconditionally deactivate the rPi,
> > >> forcing reset can also do the trick.
> You keep saying that. How? The Pi has no hardware reset, at least not up until the Pi 5, and I am unsure of its' having one.
> > > How? The kernel has panicked (or something), and the Pi is locked up. Other
> > > than removing power, how am I to reset it?
> > You haven't indicated WHICH rPi you are using. Try bringing RUN to
> > ground.
> Are youj talking about the Pico? No, this software is Linux based, and runs on the Raspberry Pi models A & B and the Pi ZeroW. There is no RUN pin.

https://static.packt-cdn.com/products/9781786467577/graphics/image_11_024.png

https://raw.githubusercontent.com/raspberrypisig/raspberrypisig.github.io/master/assets/images/rpi3runheader.jpg

https://i.stack.imgur.com/mwnCX.jpg

lørdag den 23. december 2023 kl. 14.11.31 UTC+1 skrev rhor...@gmail.com:
> On Saturday, December 23, 2023 at 6:26:40 AM UTC-6, Lasse Langwadt Christensen wrote:
> > > RESET on the PI, in hardware, you mean? AFAIK, there is no such thing.. In fact, I am almost certain of it, as it is one of the most requested things for the Pi over the years.
> > run_pg is reset, global_en controls the powersupply chip
> I think you are talking about a Pico, not a model A, B, or Zero. I don't see either of those here:
> https://www.jameco.com/Jameco/workshop/CircuitNotes/raspberry_pi_circuit_note_fig2a.jpg

top left corner of the board, "Run Header Used to Reset the PI"

On Saturday, December 23, 2023 at 6:27:35 AM UTC-6, Jan Panteltje wrote:
> >No, this is a watchdog. It must be separate from the Pi. If the Pi locks > >up - which happens a lot -
> Pis do not normally lock up, I am posting this from a Pi4 8GB

Not usually, no. I have dozens of them running 24/7, and most do not lock up very often, at all. It seems to be this software that is a bit wonky. As part of this recent project, I found out that the Pis running it reboot every few hours or so. Apparently, every once in a while, they fail to recover.

The systems running this software vary a great deal. The one here at my house is a 3B+ with a 250G SSD and a 32G SD card. The one I am testing is running on a Zero W with a 16G SD card. The only other thing directly attached is a 3.3 - 5V level shifter attached to pin 2 (GPIO 18), and of course the po5V power supply.

> It is online, posting this from it, runs many applications, a.o. firefox webbrowser,

This application is by design headless. If it finds any working IP ports, it announces their IP addresses over the audio port. If not, it brings up a default tether on 192.168.8/24.

> There must be something wrong with your code or hardware.

It's not my code. Since it happens on all types of Pis in all sorts of situations I expect it is not the hardware, but I am investigating.

> I have older Pis that had even longer uptimes, like almost a year until I had to disconnect it when I moved house...

Hmm, this is interesting. All the Pis inside my house except three are powered via POE from a Cisco 3560-E. I didn't know this previously, but they all rebooted six days ago. Something must have burped on that switch. The three that are locally powered have been up 23 days, 203 days, and 557 days, respectively. All of them are running software I wrote, incidentally.

> But.. all run from an UPS.
> Mains dips will kill a Pi, maybe that is it?

No, the one here at my house is on a battery that lasts over 48 hours when power fails. It isn't exactly a UPS, because it only supplies 12VDC and 5VDC. This is the board I use with it:

http://siliconventures.net/images/Raspberry%20Pi%20UPS%20Top.JPG
http://siliconventures.net/images/Raspberry%20Pi%20UPS%20Bottom.JPG

It is a Pi3B+ (needed for 5GHz WiFi), and it sits in a much larger enclosure with a 5 port Ethernet switch, an FM transmitter, two 120mm fans, and a very large heat sink.

On Saturday, December 23, 2023 at 7:17:51 AM UTC-6, Lasse Langwadt Christensen wrote:
> > I think you are talking about a Pico, not a model A, B, or Zero. I don't see either of those here:
> > https://www.jameco.com/Jameco/workshop/CircuitNotes/raspberry_pi_circuit_note_fig2a.jpg
> top left corner of the board, "Run Header Used to Reset the PI"
Ah, OK. 'Didn't know about that one. Do you know if it is monitored by software, or if it does a hard reset on the CPU? If it is guaranteed to reset the CPU even after a kernel panic, then that would indeed be a good choice, and much simpler. I can create a dual-use board and populate it only with a MOSFET to short those pins and see if it works. Otherwise, I can go ahead and add the power interrupter after the fact. Thanks!

lørdag den 23. december 2023 kl. 15.07.35 UTC+1 skrev rhor...@gmail.com:
> On Saturday, December 23, 2023 at 7:17:51 AM UTC-6, Lasse Langwadt Christensen wrote:
> > > I think you are talking about a Pico, not a model A, B, or Zero. I don't see either of those here:
> > > https://www.jameco.com/Jameco/workshop/CircuitNotes/raspberry_pi_circuit_note_fig2a.jpg
> > top left corner of the board, "Run Header Used to Reset the PI"
> Ah, OK. 'Didn't know about that one. Do you know if it is monitored by software, or if it does a hard reset on the CPU? If it is guaranteed to reset the CPU even after a kernel panic, then that would indeed be a good choice, and much simpler. I can create a dual-use board and populate it only with a MOSFET to short those pins and see if it works. Otherwise, I can go ahead and add the power interrupter after the fact. Thanks!

it is power good from the supply chip connected to reset of the CPU, so it should be similar to removing power