Test if it can handle external clock rates greater than 50MHz

[philipstarkey]

The Pico documentation suggests it cannot handle an external clock on a GPIO that is faster than 50 MHz. I'm not sure if that's because the chip can't handle a faster input, or if the timing is just likely to be dodgy (because the traces or whatever can't handle that speed) or because they just expected anyone who wanted to drive it with an external source at that frequency would design their own board and replace the crystal oscillator with the external signal (which we really want to avoid!) so they could use the PLL to achieve the higher frequencies.

Would be interesting to test and see! For now the readme will warn users that it should be 50MHz or less when externally referencing!

[dihm]

Why is it an issue to replace the crystal with an external clock and use the on-board PLLs? I think it would be mighty convenient to use standard 10MHz disciplined clocks (which have very high stability) but still maintain 100MHz+ performance via the PLLs.

[philipstarkey]

It's certainly possible to do, just not easy. Here is the oscillator schematic

And here is it on the board

You need to de-solder the oscillator and 3 passives, and then feed in a 10MHz CMOS signal (see section 2.3 here) between one of the the unsoldered pads visible in the red circle - whichever is XIN (the upper one in the above photo without the passive attached) and a ground pin (which I believe the closest is one of the existing oscillator pads assuming it is not destroyed in the process).

I could look at modifying the PrawnBlaster source code to support a 10MHz "internal" oscillator base frequency for this case...but I don't think most people would find it easy to do the hardware modifications required. The passives are very tiny!

FYI, assuming the pico follows the RP2040 reference design, then the external oscillator has a tolerance of 30ppm!

[dihm]

Ah, I see. I did not notice that Xin is not an exposed pin on the Pico. Fair enough. I am inclined to agree that nobody is going to bother doing that (I certainly won't, especially after I just noticed all of our pulseblasters have standard 100ppm internal clocking). Much more likely they would design their own board for the RP2040 which would require special consideration anyway.

[dihm]

I have done some testing with running the external clock higher than 50 MHz. So far it doesn't work. After setting the clock, the ok response is fine. I then just send status requests until I get a null response and the board locks up (typically only 1 request, sometimes 0). I tried 51 and 60 MHz. I also get the same behavior with 40 MHz (and a higher number of successful requests). I am suspicious there is some rounding error under the hood that is causing the serial communication to get mangled.

[philipstarkey]

I certainly won't, especially after I just noticed all of our pulseblasters have standard 100ppm internal clocking
FYI it's at least easier to externally reference the pulseblasters because you can just pull out the crystal and feed in the appropriate signal!

I have done some testing with running the external clock higher than 50 MHz. So far it doesn't work. After setting the clock, the ok response is fine. I then just send status requests until I get a null response and the board locks up (typically only 1 request, sometimes 0). I tried 51 and 60 MHz. I also get the same behavior with 40 MHz (and a higher number of successful requests). I am suspicious there is some rounding error under the hood that is causing the serial communication to get mangled.

Hmm, it's possible that this is because I'm not configuring the new clock source properly (see #1). I'll investigate! At the very least we should be able to get 40MHz (etc.) working

[dihm]

Done just a little more testing today on the clocks. For starters, I've found that external clocking at 20 MHz is also stable (along with 50 MHz).

I also realized the getfreqs command is probably helpful. I don't understand what I'm seeing. On internal clocking, clk_sys and clk_per are 100 MHz. For 50MHz external, they are 25 MHz. For 40 MHz external, they are 20 MHz until the board locks up. For 20 MHz external, they are 20 MHz. From earlier testing I was able to run programs with correct timing on 50 MHz external clocking earlier, but then the relationship between clk_per and input frequency is not consistent. Odd stuff.

[philipstarkey]

So from what I can tell, I think the problem lies with how your external clock is being interpreted by the pico.

I have a 48 MHz signal being output on pin 21 that I feed back into pin 20 for testing. If I configure the external clock to run at 24 MHz (setclock 1 24000000 0 0 0) then getfreqs still reports 48000KHz for clk_sys and clk_peri which are the important ones (pll_sys also being important for internal clock but not external clock). It seems like these values are reporting measured frequencies using an internal frequency counter on the pico and do not indicate what the intended frequency is!

So that indicates to me that your clock source is being sampled by the pico at half the frequency you expect. It might be worth checking the output of pin 21 on a DSO/CRO and seeing if our understanding of the shape/amplitude of the external clock is correct. As far as I can tell, what comes out of pin 21 is appropriate as my pico is fine with it.

FYI I will be pushing a fix to #10 for #1 which might help make the debug slightly less painful. Not going to bother pushing it to master as I think #10 is almost ready for merging?

[dihm]

Yeah, the clock stuff is vexing. I don't have a scope with me right now so I'll have to try sometime during the week.

I also forgot to mention that I determined (probably for the second time) that the clock actually needs to be a pulse train (not a standard sine). I tried a number of voltages and ultimately had to settle on 5VTTL to get reliable clocking at all. That doesn't make too much sense to me though, so I suspect there is some kind of impedance matching strangeness with my waveform generator (drives at 50 Ohms). I'll have to pick through the lab to see if I can find a better CMOS digital clock signal source, or at least a fast level converter.

I also probably need to consider getting a second pico. It's only a matter of time before my insistent 5VTTL driving blows something up.

[dihm]

So by happy coincidence, our lab accidentally ordered these eval boards which can produce arbitrary frequency CMOS clocks up to 160 MHz. What luck!

Initial tests with it have shown that my original clocking problems were indeed due to the function generator I was using, since clocking with this thing works great. I'm almost skeptical because the clock signals themselves look like abysmal square waves, but that is probably by design to cut out higher order harmonics.

For these initial tests, I just ran getfreqs and status a bunch to make sure catastrophe did not strike. I went all the way up to 100 MHz without serious problem, though the measured clk_sys and clk_per started showing some small deviation from 100 MHz (by 2kHz) intermittently. I'll have to test actual programs to see if the clocking is reliable but this does seem promising. It's also promising since my test rig right now uses test clip leads onto headers for the clock, which seems suspect for these higher frequencies, but is still functional.

I've also tested what happens if I unplug the external clock. So far, I've had about a 50% success rate of the board recovering. That is still infinitely better than always failing hard though.

[dihm]

Well I must say, this little board is amazing! Here is my typical multi-pseudoclock test code running with external clocking at 125 MHz.

And here is the associated diffs.

I do still occasionally see jitter in the measured frequencies at the kHz scale using getfeqs, but that is probably within spec since 1kHz on 125 MHz is 8 ppm.

As a reference, this is what some of the clocks look like measured into high impedance on a scope.

125 MHz

100 MHz

50 MHz

40 MHz

So I guess the short of it is that it appears external clocking the entire range is possible, but the pico has some fairly strict requirements for what the clock needs to be (ie actual DC-coupled, 0-3.3V CMOS, not just any old wavegen). Finally, for reference, this is my test rig at the moment. Note the clip leads directly onto the headers. That is the clock input. So while there are apparently some hard details, clearly the system is still fairly robust, even at higher frequencies.

[philipstarkey]

That's awesome!

I do still occasionally see jitter in the measured frequencies at the kHz scale using getfeqs, but that is probably within spec since 1kHz on 125 MHz is 8 ppm.

IIRC I think I read somewhere in one of the pico/rp2040 reference documents that the onboard counters are only accurate to 1KHz :)

Looks good though. Thanks for doing so much testing and figuring out what was needed. I'll update the readme with a link to this issue regarding external clocking capabilities!