Issue with delayed inverval interruption having a timer Crystal installed

I have installed the timer Crystal (ABS06-107 and two 4pF caps) on several Pico's (v1.3 and v1.4b, firmware 2v19) for better time keeping. I'm already using this in two clocks and it's working fine for those applications.

I'm currently working on a 7 segment flip clock timer, which should start counting immediately after power is applied to the system.

The issue is that i'm experiencing a delayed interruption on the interval that is used to update the display. So with an interval of 1000ms, the 2nd second output to display is not executed.

In order to debug the issue, i've run the code below and used a scope to measure the output:

setInterval(function(){
digitalPulse(A5, 1, 10);
}, 50);

The results (see attached images) are that after an initial bootup of 7ms, the interval starts and runs for 1,5 seconds. Then the interval/output is interrupted for ~940ms and then continues (but slower and ramps up over the next half a second or so).

This interruption does not occur on Pico's without the Crystal, so i'm assuming this has something to do with initialising/changing the clock?
Is this correct (as in intended behaviour) and/or is there something to fix this with this setup (in firmware, or code or output pin (letting LED2 blink, has the same issue, so i don't think it's pin related))?

2 Attachments

Hi - I think this is expected... Because the Pico doesn't know if it has a crystal or not it has to check, so I believe what it does is:

• Powers up using the internal RC oscillator
  
• Switches on the external oscillator
  
• Starts executing code
  
• After ~1 second it then looks at the external crystal and it it seems to be working it swaps over to using it.
  
  

But that's complicated again, because on the Pico, we wanted to be able to get accurate timing (better than 32kHz), but that timing should also match the real time clock (which only runs at 32kHz).

So we have some crazy logic that uses the processor's high speed clock counter, but then syncs that against the RTC - and it takes a while to adjust itself to the right speed, especially as it just started adjusting itself once to the internal RC oscillator and then has to readjust to the external one.

So I'm afraid I don't think there's a great deal we can do to avoid that

Hi Gordon,

Thanks for explaining it in detail! That's a bummer (for me in this particular application), but understandable.

Perhaps a MDBT42Q could be an alternative (as i assume that one does not have to swap and should be accurate), but i have no spares laying around.

I'll then use a Pico without the Crystal and a DS3231 module as an external reference. I've tested that in the meantime and seems to be a working 'alternative'.

Perhaps a MDBT42Q could be an alternative

Yes - it can self calibrate the RTC based on the high speed oscillator, but it's still not entirely accurate.

I'll then use a Pico without the Crystal and a DS3231 module as an external reference.

That's probably the best bet for a standalone clock. Even external crystals like ABS06-107 are 20ppm accuracy (so not much better than just using the high speed oscillator) , but the DS3231 is 2ppm - so 10x more accurate!