Detect low voltage PWR_LOW_N

[Milliways]

The Pi3 "PWR" LED is directly connected to the APX803 voltage monitor chip and the APX803 is connected to `PWR_LOW_N`. The kernel can detect this, and report low voltage by the rainbow square.

Is is possible for user programs to detect `PWR_LOW_N`? There seems to no /sys file which exposes this.

[Burngate]

See below. Then ignore me

Power LED is connected to GPIO-35, so reading that GPIO will tell you the state of the power (and writing to it will switch on/off the LED!) (I don't know if it'll turn on/off the low-voltage icon on the screen - try it and see)

[gregeric]

On a Pi3 GPIOs 34-39 are the SDIO interface for WiFi. PWR_LOW_N is on the GPIO expander as are the LEDs, so not accessible by reading the state hi/lo of any GPIO.

[6by9]

The FIRMWARE can see it, not the kernel.

There's a mailbox service that allows access to the GPIO expander to read states on inputs, and set states on outputs. It does not support changing direction, nor reading the state of outputs.
https://github.com/6by9/rpi3-gpiovirtbuf/ (credit to Akane and https://github.com/Terminus-IMRC/rpi3-gpiovirtbuf for the basis of this) is a very simple command line app for using that mailbox service.

GPIO 135 is the PWR_LOW_N line, so

Code: Select all

git clone https://github.com/6by9/rpi3-gpiovirtbuf.git
cd rpi3-gpiovirtbuf
make
./rpi3-gpiovirtbuf g 135

should retrieve the code, build the app, and print out the value of the power low line on a Pi3.
(I haven't got a Pi to hand to test the commands, so E&OE).

If you want to turn the LED on/off, you currently need to rewrite the pin config to set 135 as an output - see https://github.com/raspberrypi/linux/issues/1332

[Milliways]

The FIRMWARE can see it, not the kernel.

There's a mailbox service that allows access to the GPIO expander to read states on inputs, and set states on outputs. It does not support changing direction, nor reading the state of outputs.
https://github.com/6by9/rpi3-gpiovirtbuf/ (credit to Akane and https://github.com/Terminus-IMRC/rpi3-gpiovirtbuf for the basis of this) is a very simple command line app for using that mailbox service.

GPIO 135 is the PWR_LOW_N line, so

Code: Select all

git clone https://github.com/6by9/rpi3-gpiovirtbuf.git
cd rpi3-gpiovirtbuf
make
./rpi3-gpiovirtbuf g 135

should retrieve the code, build the app, and print out the value of the power low line on a Pi3.
(I haven't got a Pi to hand to test the commands, so E&OE).

If you want to turn the LED on/off, you currently need to rewrite the pin config to set 135 as an output - see https://github.com/raspberrypi/linux/issues/1332

Thanks for the answer. I tried and got output "Get state of 135 as 0" Not sure exactly what this means, I will need to get a dodgy power supply to test.

As for controlling the LED I fail to see how this would be possible, as the gate of the MOSFET controlling the LED is directly connected to the output of the APX803. The discussion on the link you posted seems rather ill-informed.

[Milliways]

Just looked more closely at the code. This states "Control Raspberry Pi 3's activity LED by using the Mailbox interface", so i am not sure 135 is the PWR_LOW_N state.

[6by9]

Thanks for the answer. I tried and got output "Get state of 135 as 0" Not sure exactly what this means, I will need to get a dodgy power supply to test.

The external signal is PWR_LOW_N - N for negative, ie active low, or 0=undervoltage.
Note at the blob config line I linked to that it says "polarity = "active_low";", so software will be inverting it for you. A status read back of 1 therefore means undervoltage, but you're getting 0 so the power rail is fine.

As for controlling the LED I fail to see how this would be possible, as the gate of the MOSFET controlling the LED is directly connected to the output of the APX803. The discussion on the link you posted seems rather ill-informed.

Well thanks for your faith in my abilities.
Please note my sig - I've worked on this chip or predecessors now since 2007, so know a fair amount about the guts of it. I also have access to the firmware source so can see what is going on inside the GPU in relation to this GPIO expander.

Read the APX803 datasheet and note that on page 2 the nRST line is described as "Reset Output Pin. Active Low Open Drain". Open drain means it will only pull down, it does not assert high which is done instead by the 10k pull up R5 on the Pi3 schematics.
It is therefore quite possible for the PWR_LOW_N line going to the SoC to be switched to an output and pull the MOSFET gate low and turn the LED off.

This has been the power LED circuit since the B+, and many people are controlling the LED this way.
The comment I made on the github issue was based on actually doing it on Tuesday evening, and it does work.

Just looked more closely at the code. This states "Control Raspberry Pi 3's activity LED by using the Mailbox interface", so i am not sure 135 is the PWR_LOW_N state.

So I missed updating a comment. Shock horror. No, I'm not going to jump to amend it. If it bothers you that much then I'll accept a pull request to correct it.
The original code by Akane was using a different mailbox command that is used for the activity LED. Check the git logs if you're that bothered.

[Milliways]

As for controlling the LED I fail to see how this would be possible, as the gate of the MOSFET controlling the LED is directly connected to the output of the APX803. The discussion on the link you posted seems rather ill-informed.

Well thanks for your faith in my abilities.
Please note my sig - I've worked on this chip or predecessors now since 2007, so know a fair amount about the guts of it. I also have access to the firmware source so can see what is going on inside the GPU in relation to this GPIO expander.

Read the APX803 datasheet and note that on page 2 the nRST line is described as "Reset Output Pin. Active Low Open Drain". Open drain means it will only pull down, it does not assert high which is done instead by the 10k pull up R5 on the Pi3 schematics.
It is therefore quite possible for the PWR_LOW_N line going to the SoC to be switched to an output and pull the MOSFET gate low and turn the LED off.

This has been the power LED circuit since the B+, and many people are controlling the LED this way.
The comment I made on the github issue was based on actually doing it on Tuesday evening, and it does work.

Thanks for the clarification, and I am sorry if you took offence. The B+ and Pi3 circuitry as per the published partial schematics is different, and and I did not know APX803 is open drain. I must admit to being influenced by the lack of /sys/class/leds/led1 and many other comments that indicate control is not possible. You must admit that most of the thread in https://github.com/raspberrypi/linux/issues/1332 is waffle, even if your comment at the end is OK - I probably stopped reading long before this. (I have no desire to control the power LED). I will of course be testing when I get the opportunity, but testing inadequate power requires more preparation.

[6by9]

The B+ and Pi3 circuitry as per the published partial schematics is different,

So they've moved R8 from being inline with the connection from APX803 (B+) to inline with the connection from the SoC (Pi3).
My guess there is that now the SoC can be configured as an output but high and the APX803 can still pull the signal low to turn off the LED. On the B+ setting the GPIO as an output would give the SoC sole control over the LED.

and and I did not know APX803 is open drain.

A little knowledge is a dangerous thing

I must admit to being influenced by the lack of /sys/class/leds/led1 and many other comments that indicate control is not possible. You must admit that most of the thread in https://github.com/raspberrypi/linux/issues/1332 is waffle, even if your comment at the end is OK - I probably stopped reading long before this. (I have no desire to control the power LED).

It isn't currently controllable directly from the kernel, hence no /sys/class node.
The first 50% of that issue (by length at least) is discussion which I'd say is pretty much on topic of why things are different, and the other 50% is directly discussing the dt-blob and rpi3-gpiovirtbuf usage. Not directly relevant to you if you have no desire to control the LED, but still relevant to the discussion.
*edit*: Also worth saying that popcornmix and pelwell involved in that issue are both highly competent engineers who are employed by Raspberry Pi Trading, so are even better informed than I am on the goings on of the Pi.