ATXRaspi 2.8 and Windows IoT

[mjmeans]

I'm using ATXRaspi 2.8 with USB-A, 2.1mm power socket, and right angle headers. The 2.1mm power socket was purchased from a local electronics shop. It had larger solder tails rather than pins, so I just trimmed them smaller so that they would fit into the PCB. I'm powering a Raspberry Pi 3 with official 7" touch screen.

I've connected the ATXRaspi using the instructions here for momentary push button and GPIO. I'm using pins 2 & 6 for power and pins 24 & 26 for GPIO as indicated. I' also using pins 4 & 9 to power the Raspberry Pi 7" touch screen.

When pressing the power button, the small green light on the ATXRaspi comes on dimly, but the RPi doesn't boot and the STATUS LED doesn't light or blink. If I long press, then the green light turns off.

When the green light on the ATXRaspi is off, but power plugged in, I've measured the following voltages between the USB shield (GND) and the 2x3 header near the uUSB port. Pin1: 3.6mV, 2: 5.26V, 3: 5.10V, 4: 5.26V, 5: 4.95V, 6: 0.0mV. After I push the power button and the ATXRaspi green light turns on, the measured voltages at the output pins near the USB-A port are: Pin+: 5.26V, Pin-: 2.98V. So the voltage between - and + on this port is only 2.28V!

What is the problem?

[mjmeans]

New information. Powering the RPi form the USB-A connector on the ATXRaspi is working. Connecting power using the 4-pin header near the USB-A port is not. I would really like the 4-pin header version to work, for space reasons in my project case.

The small green light on the ATXRaspi comes on very dimly. After shut down of the RPi this light stays on dimly. I have not installed any scripts yet.

[Felix]

The USB power pin and the header power pin are the same voltage bus. It's not possible for the USB to work and the header to not, unless there's a problem somewhere in between.
Based on what I've seen in other reports, the problem has always been either a soldering issue, loose connections, weak/thin wires that can't carry enough current, shorts, and what not.
I suggest carefully checking everything, and I would ask if you could post a closeup of your setup including the ATXRaspi.
I can always offer to service the board but there's a number of steps you can do yourself to save the time of a return. I have yet to see a truly faulty board being returned.

[mjmeans]

I will double check tomorrow. The jumpers I'm using are the ones that come with the official Raspberry Pi 7" touch screen and are supposed to be suitable for at least the power that the touch screen requires. The power supply I'm using is a 5.25V 2.5A designed for the Microsoft Surface Tablet. It certainly should be good enough, if not overkill. I have seen some RPis complain (lightning symbol) about voltages over 5.2V so I may need to go to a 5.1V supply like the official RPi supplies for improved stability.

Also, my application is for Windows 10 IoT. I'm writing a Windows 10 IoT Background App that performs the same job as your Raspbian script. However it takes Windows 10 IoT a significantly longer time to reboot or shut down compared to Raspbian. I'm seeing bootup time of about 75 seconds; shutdown time about 30 seconds; and, reboot time is typically around 90 seconds. Do you anticipate these long time posing a problem for ATXRaspi?

[Felix]

The voltage warning is an undervoltage warning, as far as I know. So even if your supply is very good, the wiring to the Pi is crucially important to be very good quality. Flimsy thin or poorly crimped wires will cause voltage drops (they introduce resistance due to poor connections) and hence cause the undervoltage. That confuses a whole lot of people that use very good supplies, and makes them think the ATXRaspi is somehow causing this or other power related issues. I have put up numerous warnings in the forum and in the guide page about this problem. If you see the voltage warning, the wiring is not good enough, need better wires with stronger grip to the headers.
So again, it's very important to have:

• solid clean solder joints of the headers themselves (on the power side especially)
• high quality dupont wiring, or ideally soldered wiring to the board (I would recommend at least GA22 thick stranded wire).

The same is true for USB connections. The USB connector needs to be soldered well, flux/residue cleaned up, then the USB cable needs to be good quality and ideally short, to carry the current to the Pi without significant voltage drop.
FWIW I do offer USB cables and sets of wiring for ATXRaspi in the store, which were verified to not have the voltage drop problem.

RE the windows10 slowness - i'm sure it is not due to ATXRaspi which is just a hardware switch and the signals coming out of it are real time, not software driven, unlike windows10 which is probably the cause for it running the script and responding very slowly. You're the first person to report using this with Pi+Windows10.

[mjmeans]

I'm now having some different issues with Windows IoT implementation. Short presses are correctly resetting the RPi but long presses are not rebooting. I'm wondering if the cause may be a signal difference between the scripts call to GPIO.cleanup() mode and how Windows IoT handles this. In Windows IoT, closing the pin returns it to it's RPi default state.

So what I find when I look at RPi docs here is that GPIO pins 7 and 8, by default, starts with High Pull Up.

When booting (before the script) the BOOT pin is pulled high by the Rpi. Upon successful boot, the ATXRaspi script calls GPIO.setup(BOOT, GPIO.OUT, initial=GPIO.HIGH). So the pin is pulled HIGH initially by the RPi (visible by the dim green light on the ATXRaspi); then driven HIGH (as an output) by the ATXRaspi script (visible by the bright green light on the ATXRaspi). After shutdown or reset call by the script the loop exits to the finally block and it calls GPIO.cleanup(). At this point I assume that the pin returns to it's default mode as Input Pull Up, however, I don't see the green light dim before shutting off.

1. It seems that ATXRaspi would not see any change for the BOOT pin level before or after the script starts or exits unless the ATXRaspi board is using a comparator or is has a stronger internal pull down than the RPi's built-in pull up. So do I understand the correct operation of ATXRaspi with respect to the BOOT signal?

2. If GPIO.cleanup is not returning the port to it's default initial mode of input pull up, and ATXRaspi needs to keep the strong pull up signal to be able to handle the shutdown process, then this may be why the Windows IoT code is failing.

Mark

[Felix]

The ATXRaspi board is OS agnostic, it's just a power switch, a very simple one, it does not care about what it switches. It can switch any target that can abide by the expectations of the two signals: Which are simply the following, repeating it here for the record although it's illustrated in the guide, videos, etc:

- BOOTOK is an input
- SHUTDOWN is an output

Of course the Pi can set those pins to inputs or outputs, but you should have control over GPIO from the get go. Input pullup should be high impedance, which may cause the BOOTOK to be very dimly lit, not nearly enough to trigger a HIGH on ATXRaspi.

I can say it works for all people on Raspbian. You're the first user I know of using it with Windows IoT, the OS certainly can screw things up and windows has a tradition of doing that consistently in the past decades I've used it
Even so from what you describe I don't see why you could not set it up the same logically as on Linux.