-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Test if it can handle external clock rates greater than 50MHz #6
Comments
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. |
It's certainly possible to do, just not easy. Here is the oscillator schematic 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 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! |
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. |
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 |
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 |
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 ( 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? |
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. |
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 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. |
That's awesome!
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! |
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!
The text was updated successfully, but these errors were encountered: