That's quite a complex circuit if you take in account the real parasitic capacitance and inductance, It could generate higher (current) transients than you might think. which can destabilize the relatively weak crystal oscillator. I could be happening internally on power rails, externally by cross talk ... usually both, to make it worse.
Maybe the GPIO_SLEW_RATE overdrives somehow, and it becomes that last critical drop in an already more than full glass. These are hard to catch even with a performant oscilloscope.
Maybe also an output buffer could help, an external (shielded) oscillator etc.
What I haven't checked is driving at low frequencies, usually there you might want a softer edge.
But GPIO_SLEW_RATE is by default disabled (0) ... need to check where is used by them, maybe Flash QSPI pads.
You can also check the stability of the oscillator by getting out the sys clock on a GPIO and do a signal integrity test on scope.
Thanks for the info !
Maybe the GPIO_SLEW_RATE overdrives somehow, and it becomes that last critical drop in an already more than full glass. These are hard to catch even with a performant oscilloscope.
Maybe also an output buffer could help, an external (shielded) oscillator etc.
Hmm ... they don't say how they are limiting other than strength drive.* Slew rate limiting increases the minimum rise/fall time when a GPIO output
* is lightly loaded, which can help to reduce electromagnetic emissions.
* \sa gpio_set_slew_rate
What I haven't checked is driving at low frequencies, usually there you might want a softer edge.
But GPIO_SLEW_RATE is by default disabled (0) ... need to check where is used by them, maybe Flash QSPI pads.
Usually they don't don't expect that, but sometimes they do, and they are really helpful.Maybe some RPI expert can tell us more details.
You can also check the stability of the oscillator by getting out the sys clock on a GPIO and do a signal integrity test on scope.
Thanks for the info !
Statistics: Posted by gmx — Sat Nov 30, 2024 4:59 pm