pigpio
pigpio copied to clipboard
joan2937
Hardware PMW function not working on Pi4B revision 1.4
From https://forums.raspberrypi.com/viewtopic.php?t=329394
My team has built a custom hat which we use for controlling LEDs and Fans. This hat uses hardware PWM for controlling the fans. We've just tested it on a Raspberry Pi Model 4B rev 1.4 for the first time, and it looks like hardware PWM is no longer working. The hat is working fine on both Raspberry Pi model 3B+ and Raspberry Pi model 4B rev 1.2. We're curious if more people are running into similar issues?
We use Pigpio V79, and have tried this on three brand new Raspberry Pi Model 4B rev 1.4s, straight out of the box. All have the same issue. We've measured the PWM signal on GPIO12 (pin 32) using an oscilloscope. With the Rev 1.4 Pis, we get no signal. On the Rev 1.2 Pi or RPi3b+ we do measure the expected PWM signal.
Not sure how we can action this. I don't have a Pi4B revision 1.4 board and I guess that will be needed to identify the problem and fix.
Right, mine are revision 1.1
Oddly, one of the first searches I hit on rev 1.4 turned up an article about the changes having something to do with the USB-C interface confusing the root hub that it was an audio device. Perhaps we should ask the OP of they can try a generic/dumb USB-C cable (as opposed to the electronically marked or e-marked USB-C cable variety).
OP here. I ran the v79 as requested by Joan, with all tests passing except for one in x_pigs (ERROR: No more CBs for waveform). Full logs here: pigpio-v79-pi4b-rev14-tests.txt
The cable we use is as dumb as it gets: a USB-C cable with only the +5V and GND wires connected to a dedicated 5V, 10A PSU (Mean Well MPM-65-5ST). We never had any power/throttling issues with this one.
We may be able to help with testing. We have a single rev 1.1, and a bunch of rev 1.2 and rev 1.4 boards, as well as CM4s + IO board. Let me know if there's anything you want us to check.
The board I used for testing has 2711ZPKFSB06C0T type indicator on the CPU cover. From Googling this seems to indicate a C0 stepping.
Stranger and stranger. The default tests use the PCM peripheral to pace DMA for GPIO sampling but will use the PWM peripheral for waves. So the PWM peripheral is working to an extent.
Could you possibly do another test as follows.
sudo killall pigpiod # make sure daemon stopped
sudo pigpiod -t0 # start the daemon with the PWM clock
./x_pigs
Interesting. Be patient for a quarter hour or so. I have another test in mind.
Could you run the following Python with the normal daemon.
sudo killall pigpiod
sudo pigpiod
python3 test_hp.py
import pigpio
import time
G=12
TEST_TIME=5
pi = pigpio.pi()
if not pi.connected:
exit()
cb = pi.callback(G)
for freq in [1, 10, 20, 50, 100, 200, 500, 1000, 2000, 5000, 10000, 20000, 50000]:
pi.hardware_PWM(G, freq, 500000)
cb.reset_tally()
time.sleep(TEST_TIME)
print(freq, cb.tally()/TEST_TIME)
pi.stop()
Sure, results here:
pi@pi-rev14:~/pigpio-79 $ sudo killall pigpiod
pi@pi-rev14:~/pigpio-79 $ sudo pigpiod
pi@pi-rev14:~/pigpio-79 $ python3 test_hp.py
1 0.8
10 8.4
20 19.8
50 49.8
100 100.0
200 200.0
500 500.4
1000 1000.0
2000 2001.8
5000 5005.0
10000 10010.0
20000 29.4
50000 49149.0
The results for the 20k freq look strange. Ran the test again, same results:
pi@pi-rev14:~/pigpio-79 $ python3 test_hp.py
1 1.2
10 8.2
20 19.8
50 49.8
100 99.8
200 200.2
500 500.6
1000 1001.0
2000 2002.6
5000 5004.6
10000 10010.8
20000 26.0
50000 49380.8
Will try these on a rev12 board as well and report back
Odder and odder. That looks okay apart from 20 kHz which seems to be wrong.
Could you try with GPIO 13 (rather than 12).
Rev 12 results (still with GPIO 12):
1 1.2
10 8.2
20 19.8
50 49.8
100 100.0
200 200.0
500 499.8
1000 1001.0
2000 2000.8
5000 5004.6
10000 10009.0
20000 19909.8
50000 49767.8
Will try with GPIO 13 in a minute on both revisions
GPIO 13 looks ok on both rev 1.2 and rev 1.4:
pi@pi-rev14:~/pigpio-79 $ python3 test_hp_gpio13.py
1 1.2
10 8.2
20 19.8
50 49.8
100 100.0
200 200.2
500 500.8
1000 999.8
2000 2000.0
5000 5004.4
10000 10009.6
20000 19875.8
50000 33584.2
pi@pi-rev12:~ $ python3 test_hp_gpio13.py
1 1.2
10 8.2
20 19.8
50 49.8
100 100.0
200 200.0
500 500.0
1000 1000.0
2000 2001.8
5000 5004.4
10000 9999.4
20000 19967.4
50000 49777.0
Ran the tests on a rev 1.1 as well, with similar results as the rev 1.2 (both GPIO 12 and 13 work as expected)
Odd and odder. For your use could you use GPIO13 or GPIO19 rather than GPIO12? Might be a temporary fix.
I'm discussing the use of GPIO13 with my team. Meanwhile I'm trying to pinpoint the starting/end frequencies of this strange behaviour. I'm still narrowing it down, but it looks like it's not just 20Khz, more like 11Khz-45Khz.
When you do the tests do you use the same SD card in each Pi and do they have the same peripherals connected?
We have had odd results before but never managed to identify a reason or pattern.
On the rev11 and rev12 Pi's I used an existing os installation, on both devices with different peripherals connected. On the rev14 Pi I used in the above test I've disconnected all peripherals before testing, except for a Raspberry pi 7" touchscreen and ethernet cable.
Regarding the start / end frequencies:
pi@pi-rev14:~/pigpio-79 $ python3 test_hp_11khz.py
11300 11308.8
11305 11305.6
11310 11322.6
11315 11317.8
11320 11321.8
11325 11324.2
11330 11340.2
11335 11344.4
11340 11341.4
11345 11346.4
11350 11360.6
11355 11365.0
11360 6913.8
11365 6901.4
11370 6864.4
11375 5866.6
11380 6777.6
11385 7352.6
11390 8480.4
11395 8154.2
11400 46.0
11405 40.4
11410 31.6
11415 38.0
11420 46.6
11425 33.8
pi@pi-rev14:~/pigpio-79 $ python3 test_hp_45khz.py
45700 8.0
45705 3.0
45710 1.2
45715 3.8
45720 3.4
45725 4.0
45730 3.8
45735 1.6
45740 1.4
45745 4.6
45750 2.6
45755 2.0
45760 2.2
45765 2.6
45770 222.4
45775 31.8
45780 45705.8
45785 45826.8
45790 45723.2
45795 45699.8
Thanks for that. Does seem suspiciously like audio. Guy and myself will have to give this some thought. We probably do need input from the Foundation unless we find some queer bug in our code.
I'll run a few more tests to try to figure out which models (Model 4B & CM4) & OS combinations are affected. And ask if we can get some assistance from the Foundation for this issue. It looks like we have to create and produce a revision of our pcb to use GPIO 13, which would delay things on our end quite a bit. A workaround or fix would be most helpful. I'll also have a look if disabling audio will have any effect.
ERROR: No more CBs for waveform
This is an expected, good, result from the test. I was lazy and never went back in the code to suppress it. Please ignore.
On the rev14 Pi I used in the above test I've disconnected all peripherals before testing, except for a Raspberry pi 7" touchscreen
I believe we have seen HDMI connections turn audio on in some configurations and cause conflict with pigpio. Could you run the rev 1.4 units headless just be verify this is not a factor?
I've disconnected the DSI cable so the rev 1.4 test pi is now fully headless (with both Wifi & ethernet connected). The results are slightly different, now also giving problems at 10khz:
python3 test_hp.py
1 1.2
10 8.2
20 19.8
50 49.8
100 100.0
200 200.0
500 500.8
1000 1000.4
2000 2002.6
5000 4662.8
10000 13.6
20000 301.6
50000 48260.8
The board I used for testing has 2711ZPKFSB06C0T type indicator on the CPU cover. From Googling this seems to indicate a C0 stepping.
Note to ourselves: C0 has changes allowing DMA to access greater memory ranges. Hopefully firmware APIs did not change.
Ran above test_hp.py on pi400 (presumably uses C0 stepping, I haven't looked inside):
1 6.8
10 8.2
20 19.8
50 49.8
100 99.8
200 200.2
500 500.2
1000 1000.8
2000 2001.8
5000 5000.0
10000 3874.2
20000 23.4
50000 49745.0
I've tested the issue with the Rev 1.4 Pi on all four latest OS builds (32/64-bit, Buster/Bullseye) using a slightly modified test_hp.py script. Same results, with varying frequency ranges that show the anomaly. I will check on the CM4 next.
Logs: 4b-rev14-buster32.log 4b-rev14-buster64.log 4b-rev14-bullseye32.log 4b-rev14-bullseye64.log
Note that hardware is reported as BCM2835 in the 64-bit builds
test_hp.py modified:
import pigpio
import time
G=12
TEST_TIME=5
pi = pigpio.pi()
if not pi.connected:
exit()
cb = pi.callback(G)
def test(freq):
pi.hardware_PWM(G, freq, 500000)
cb.reset_tally()
time.sleep(TEST_TIME)
print(freq, cb.tally()/TEST_TIME)
print("Basic test:")
for freq in [1, 10, 20, 50, 100, 200, 500, 1000, 2000, 5000, 10000, 20000, 50000]:
test(freq)
print("\nFinding start:")
for freq in range(5000, 12000, 200):
test(freq)
print("\nFinding end:")
for freq in range(43000, 48000, 200):
test(freq)
pi.stop()
@joan2937 , please checkout this post from raspberrypi.stackexchange.com
To fix their u-boot issue, they had to change the virtual address of the XHCI PCI device! (see link to patch).
The CM4 rev 1.0 has the issue too. This one also has a C0 stepping (same type number on the SOC).
Unfortunately, I was a bit too quick to say GPIO13 is ok. I was focusing on the 20Khz counter, but overlooked 50Khz. If you look at the results for the test with GPIO13 on the rev14 above, you'll notice 50Khz is off as well (the counter is at 33k). I've repeated this test a couple of times this morning, and getting similar results (counter at 5854 in one test, 7691 in another).
I've run the test in the range our fans support [20khz-28khz], and it starts breaking down at around 23Khz:
$ python3 test_hp_gpio13_fan_range.py
20000 19991.6
20200 20209.2
20400 20264.8
20600 20678.4
20800 20906.8
21000 20971.6
21200 21059.2
21400 21606.8
21600 21561.0
21800 21798.4
22000 22000.8
22200 22107.2
22400 22465.2
22600 22813.6
22800 22814.2
23000 5767.0
23200 5953.0
23400 5375.4
23600 6139.0
23800 5222.6
24000 6147.0
24200 5932.2
24400 6838.4
24600 4942.0
24800 5524.4
25000 5293.8
25200 5472.6
25400 6258.0
25600 5639.8
25800 6061.0
26000 6405.4
26200 5974.6
26400 6167.2
26600 6220.2
26800 5827.0
27000 6405.6
27200 6070.4
27400 5730.8
27600 6601.8
27800 6253.4