Open judemiller opened 7 years ago
Hi there and thanks for brining this up.
I suggest that you join the Raspberry Pi forums and post your question about the anomalous clock ranges there. I would think this sub-forum:
https://www.raspberrypi.org/forums/viewforum.php?f=72&sid=f334f2924451d7da13859db298abb573
would be the most appropriate.
It's been a while since we created the little Guzunty support library. It's possible the the base clock frequencies have changed as newer models have come out. In the meantime, I'll get my own scope out and decide how to rename the constants, though they may have to be called SLOW_CLK and FAST_CLK with model specific values in a comment for backwards compatibility.
I knew there was a reason we kept all those old Raspberry Pi's around. :-)
I have a RPi 3 and a scope.
What code am I running and what pin am I monitoring ?
It sounds like Bit 1 of the divisor is being forced to the set position regardless.
From: judemiller notifications@github.com Sent: 22 September 2016 00:37 To: Guzunty/Pi Subject: [Guzunty/Pi] RPi 3 GPCLK0 Anomaly? (#47)
This is not a Guzunty Pi issue, but may be of interest to Guzunty Pi users. Also, I'm new to RPi-land and am not sure where to post this.
RPi 3 GPCLK0 Anomaly
Using a modified version of GZ_TEST, I measured GPCLK0 frequencies (default XC9572XL global clock) with various divisors and clock sources. There's an anomaly: using either clock source, the divisor acts like bit 1 is set, whether it is or not. So the sequence of divisors
2, 3, 4, 5, 6, 7, 8, 9, 10, 11, ...
produces frequencies as if the divisors were
2, 3, 6, 7, 6, 7, 10, 11, 10, 11, ...
This behavior occurs for both the fast (GZ_CLK_125MHz, actually 500 MHz) and slow (GZ_CLK_5MHz, actually 19.2 MHz) clock sources and anywhere I checked for it. I tested the first dozen or so values, some in the 100 range, and some in the 4000 range. This suggests that the problem is not related to the input or output frequency, but more likely a bug in the BCM2837 internal logic. Without a datasheet or errata, I don't know if this behavior is already known. Seems unlikely to be confined to my Pi 3, though.
I made these measurements with the Guzunty Pi attached, although I suspect this is not a factor. I would be happy if someone else with an RPi 3 and appropriate instruments could confirm or contradict my results. Thanks.
P.S. I'm new to RPi, but not new to hardware. I used my trusty Tek 2465B 400 MHz scope for all measurements, suitable grounding, etc.
You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/Guzunty/Pi/issues/47, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AF2FR2m4o-Lec-8jos66E1h9Sk327HrLks5qsc2sgaJpZM4KDa2G.
Thanks. The RPi pin is GPIO4, pin 7 on the RPi I/O header, the fourth one down the pin 1 side. The Guzunty Pi is not necessary for this test, but I did use Derek's GZ_TEST code as a starting point. If you have not already set this up, I will have to package up some code for you to use. Otherwise, I just added a few lines of code to gz_test.c to allow me to enter the divisor on the command line.
int main(int argc, char* argv[]) { char aChar; unsigned divisor = (argc>=3) ? atoi(argv[2]) & 0xfff : 0xf;
gz_clock_ena(GZ_CLK_125MHz, divisor);
printf("\nPress any key to stop test.");
scanf("%c", &aChar);
gz_clock_dis();
return 0;
}
(Apologies if the following is obvious to you.) You will need a scope with reasonable bandwidth, 100 MHz or better. You will need to ground the scope probe reasonably close to the pin you are observing.
No Apology needed, I'm kind of new on the RPi side of things. I am quite experienced with RF and electronics but I am 100% new to github,
I did grab this zip file ... do I want to compile src\gz_test\gz_test.c with the gcc compiler? from
Best Regards,
John.
I just followed the Guzunty Pi setup guide at
https://github.com/Guzunty/Pi/wiki/Get-your-Pi-set-up
It looks daunting but goes quite quickly if you cut and paste. I didn't do the optional steps. I did encounter one problem: a compile failed with a message about a -W flag it didn't like. The flag -Wl (lowercase L) should be replaced by -Wall in src/gz_test/Makefile. This is noted earlier here (GitHub Guzunty Pi) as Issue 29.
I modified gz_test.c as shown in my previous comment. This allows commands like
sudo ./gz_test 0 12
to set a divisor of 12. The first argument is ignored; I was going to play with the clock sources but didn't get around to it.
Anyway, use the command line to try a bunch of divisors 2 (if your setup can handle 250 MHz) and up. I haven't tried it without a Guzunty Pi. If you don't have one, skip the steps about programming the logic chip. I think the test program just controls the input clock values and that's the presenting issue.
This is not a Guzunty Pi issue, but may be of interest to Guzunty Pi users. Also, I'm new to RPi-land and am not sure where to post this.
RPi 3 GPCLK0 Anomaly
Using a modified version of GZ_TEST, I measured GPCLK0 frequencies (default XC9572XL global clock) with various divisors and clock sources. There's an anomaly: using either clock source, the divisor acts like bit 1 is set, whether it is or not. So the sequence of divisors
produces frequencies as if the divisors were
This behavior occurs for both the fast (GZ_CLK_125MHz, actually 500 MHz) and slow (GZ_CLK_5MHz, actually 19.2 MHz) clock sources and anywhere I checked for it. I tested the first dozen or so values, some in the 100 range, and some in the 4000 range. This suggests that the problem is not related to the input or output frequency, but more likely a bug in the BCM2837 internal logic. Without a datasheet or errata, I don't know if this behavior is already known. Seems unlikely to be confined to my Pi 3, though.
I made these measurements with the Guzunty Pi attached, although I suspect this is not a factor. I would be happy if someone else with an RPi 3 and appropriate instruments could confirm or contradict my results. Thanks.
P.S. I'm new to RPi, but not new to hardware. I used my trusty Tek 2465B 400 MHz scope for all measurements, suitable grounding, etc.