Go Down

Topic: Arduino turns on RPI0w power after power up and maintain power between resets (Read 355 times) previous topic - next topic

liuzengqiang

I'm trying to have arduino pro micro with 32u4 attached to USB port and power a raspberry pi 0w that's connected to arduino. I want to do this properly, only turning on pi after 32u4 finishes USB configuration as 500mA device. So I need a P-MOSFET. The tricky part is arduino is connected to pi via SPI so pi can update arduino's firmware. When arduino reboots after firmware upload or due to programmatically rebooting to enumerate a different USB descriptor, I don't want pi to lose power. I wish 32u4 has some strapping pins that I can set before external reset so it would hold the gate of the P-MOSFET low but there isn't. What should I do to hold the gate?

I thought about caps but that's not proper. I need a steady logic level. Should I add an IC say an I2C GPIO expender that has hi-Z state at power on so I can have the MOSFET gate pull up for initial power on but then have 32u4 set the IC output pin to output low? This way arduino can reset and the IC will keep rpi power steady.

Any suggestions? Thanks.
Serial LCD keypad panel,phi_prompt user interface library,SDI-12 USB Adapter

liuzengqiang

Thinking along the path that the P-MOSFET needs to be held low, I can use a pi GPIO to hold it low through an N-MOSFET level shifter once pi boots up. This way when pi flashes arduino or when arduino resets, power to pi won't be lost. Sounds like a solution?
Serial LCD keypad panel,phi_prompt user interface library,SDI-12 USB Adapter

ron_sutherland

Will the R-Pi get power through that PMOS that it is to control? That won't work, but it might be fun to debug. I have some history with keeping an AVR powered that the R-Pi can bootload, while at the same time the AVR can power down the R-Pi, it is chickens and eggs, and turtles on the back of turtles.
my projects: https://github.com/epccs

liuzengqiang

Ron,

Could you give me some critique? Here is the circuit:


I have an N-MOSFET as bidirectional shifter. Left side is pi GPIO4 at 3.3V. Right side is Arduino D5 at 5V. P-MOSFET is on the right side.

Here is the sequence of events:
Power on initially, arduino is in reset, R18 pulls P-MOSEFT HIGH, disconnecting Pi from power. Arduino D5 is in high-z state
Arduino completes set_configuration response from USB host and sets D5 to LOW, turning on pi's 5V rail.
Pi boots up and sets its GPIO4 to LOW.
Pi flashes Arduino via SPI bus. Arduino is in reset state and D5 is in high-z state so P-MOSEFT is still low due to pi's GPIO4 being LOW.
Arduino completes flashing and runs again. It sets D5 to LOW (no effect, it's already LOW).

In the whole process, neither arduino nor pi will ever set their pins to HIGH. The HIGH is only achieved at initial power on with R18.
Serial LCD keypad panel,phi_prompt user interface library,SDI-12 USB Adapter

ron_sutherland

#4
Sep 14, 2019, 10:36 pm Last Edit: Sep 14, 2019, 10:45 pm by ron_sutherland Reason: d5
LOL, I just found a mistake with a level shifter the other day that I had done. Yours looks right, and that stuff is fresh in my mind.

My guess is the circuit will be pulled down by the R-Pi's ESD diode until it powers up. Then the GPIO can be used to cut-off the NMOS, which should cause the PMOS to be pulled up into cut-off.

Unfortunately once the R-Pi losses power it's ESD diode will pull down the GPIO. I am having flashbacks; it was good times.

update: I did not consider D5, but I don't think that changes anything I said.

update2: if nether the R-Pi or AVR will let the D5 node go high, then why connect it to them?
my projects: https://github.com/epccs

liuzengqiang

Ron,

Could you elaborate on the ESD diode on rpi a bit? It's new for me.
The goal is to only power up RPI once and keep it powered up. On power up, the pullups will keep P-MOSFET from supplying power to RPI until arduino sets its D5 to LOW. Once RPI powers up, it will use its own GPIO4 to output LOW to keep the P-MOSFET LOW, regardless arduino resetting thus losing LOW on its D5.
Serial LCD keypad panel,phi_prompt user interface library,SDI-12 USB Adapter

ron_sutherland

AVR's have ESD diodes also. If the part (AVR or the Broadcom System on Chip) pin is pulled below ground enough (.7V) its ESD  diode will conduct, if it is pulled above VCC (+.7V), the high side diode will conduct.  That means if the R-Pi has no power, its pins should not go above .5V to be conservative.

The R-Pi's are not very good USB things (e.g., like Arduino's); I wonder if that idea has something to do with having a USB connector for power (imagine if that was screw terminals, would your ideas change?). My thinking is that the R-Pi needs to act as a general-purpose host computer just like my desktop. Well almost, I want my AVR to keep power even when the R-Pi is powered off, so that is different than the Arduino desktop interface, but I do want to be able to bootload from the R-Pi.

If the R-Pi is going to be powered off while the AVR has power we have to explore the idea of IOFF buffers, that is the only thing I know that will allow connected circuits to have areas that are powered off. We could use one between the GPIO and D5 and power it with the R-PI3V3 (e.g., the R-Pi's logic reference voltage). I got to do some part digging for my own project, so let me see if I can find a part in a SOT23 sized package.
my projects: https://github.com/epccs

liuzengqiang

Ron,

Thanks. I understand your concern now. It's about power leaking into RPI via that GPIO4 pin. It's a real concern. If you were trying to do this, keeping RPI power while arduino can be reset, would you rather use a 3rd IC to hold power for RPI instead, such as an attiny or an I2C port extender?
Serial LCD keypad panel,phi_prompt user interface library,SDI-12 USB Adapter

ron_sutherland

The part I wanted to find was this:

https://www.digikey.com/product-detail/en/diodes-incorporated/74LVC2G07DW-7/74LVC2G07DW-7DICT-ND/4505239

the part I have been using is this

https://www.digikey.com/product-detail/en/diodes-incorporated/74LVC07AS14-13/74LVC07AS14-13DICT-ND/4505119

I would try an IOFF buffer, like this.




Update:

Since the R-Pi powers the IOFF buffer it will be Hi-z until D5 turns on the power.

Looking some more and I can't think of a reason to connect the GPIO pin. Just connect the buffer input to the ground rather than the R-Pi GPIO.
my projects: https://github.com/epccs

ron_sutherland

One more try that PMOS was wrong.



Update: regarding the use of the SPI from R-Pi to upload to a 32u4, I have used the avrdude -c linuxspi, but it does have some issues. At this time, I consider it a toy; in other words, I would not do a board that I expected to work based on it. I will link my setup that sort of works with it. It has a lot of IOFF buffers to look at also.

https://github.com/epccs/Driver/tree/master/ICSP
my projects: https://github.com/epccs

liuzengqiang

Ron,

Thanks for your help! I decided to include a PCF8547 controlled by arduino 5V I2C bus to hold the P-MOSEFT. This way there is no need to worry about leaking power to pi pins when pi is not powered. I'll make sure all arduino SPI pins and TX RX are set to OUTPUT LOW.
Serial LCD keypad panel,phi_prompt user interface library,SDI-12 USB Adapter

ron_sutherland

After disconnecting the IOFF buffer it is looking silly even to have the buffer, maybe that NMOS level shift should just be used to latch instead. But your plan sounds fine.
my projects: https://github.com/epccs

liuzengqiang

Only one thing I just realized, the reset pin is still pulled high so that will conduct somewhat while pi is off. Maybe I should use opto-couplers on pi side to pull reset low. Too many components. I have a solder jumper in case this doesn't work and I want a direct connection between arduino and rpi 5V and just forget about the usb current requirements. :)
Serial LCD keypad panel,phi_prompt user interface library,SDI-12 USB Adapter

ron_sutherland

#13
Sep 16, 2019, 10:57 pm Last Edit: Sep 16, 2019, 11:23 pm by ron_sutherland Reason: image
I removed the IOFF buffers to see how that might look... and I think the IOFF buffer is better, but the NMOS LATCH seems right.  In this image, I am trying to be mindful of the ESD voltage range.



I have IOFF buffers on the SPI port of that project I linked at the bottom of post #9; they need to be powered from the R-Pi side for your project so that they will Hi-Z when the R-Pi is powered off (that project has them powered on the AVR side, the ISP target).
my projects: https://github.com/epccs

ron_sutherland

#14
Sep 17, 2019, 01:09 am Last Edit: Sep 18, 2019, 02:01 am by ron_sutherland Reason: latch is wrong
The big picture, though I don't have a 32u4 I can cut and paste (so pretend I guess).



There are two PMOS (DMB is marking), several NMOS (K38 marking), and the usual stuff.

Looking from a generic point of view, I think it would be nice if the R-Pi could be powered off, it should be safe if the R-Pi has finished a shutdown. This link shows what I have been doing for the shutdown script.

https://github.com/epccs/RPUpi/tree/master/Shutdown

Update: image changed so D5 can power off the R-Pi. The latch will hold when D5 floats so the R-Pi can program the AVR (D5 will Hi-Z during programming).

Update: Latch above is wrong, don't do that.

Update: fixed bellow

my projects: https://github.com/epccs

Go Up