Page 1 of 1

Would varying the clock input mess with the PLL?

Posted: Mon Sep 07, 2020 2:48 pm
by arcadebench
I'm another one who is attempting to implement an I2C slave in a microcontroller to emulate an external EEPROM. Mine is an ATSAMD21 from Atmel / Microchip. Just like others from that brand of microcontrollers, the on-board I2C slave wants to pause the SCL clock line to give the micro software enough time to respond to bus accesses. Unfortunately it looks like the FV-1 isn't equipped to play nice with the pause, and it keeps going as if the clock was uninterrupted. The one mitigation that seems effective is to slow the FV-1 clock down enough so that the micro isn't compelled to pause the SCL line.

Running the FV-1 at 46.5kHz seems to allow the I2C to run at around 384kHz. Slowing the input clock to 5.75kHz also slows the I2C down to about 45.5kHz, which looks comfortable enough for the ATSAMD21 to not pause the SCL. I'm guessing there's a clock output from an 8x PLL somewhere that's feeding the circuit for the I2C in the FV-1. What I would like to do is slow the clock down enough for the FV-1 to pick up the external programs from the I2C slave in the microcontroller, and then kick the clock back up to 46.5kHz for DSP operation. What would this do for the PLL and the rest of the chip? Would we be able to execute such clock chicanery and still have reliable operation from the FV-1?

Re: Would varying the clock input mess with the PLL?

Posted: Wed Sep 09, 2020 9:49 am
by frank
Officially we do not support such a thing. PLLs like to lock to a stable and fixed clock.

Unofficially, it is possible but you have to slowly and smoothly move the clock from one frequency to the next or else you could cause the PLL to lose lock and have to re-acquire lock which could mean missed or skipped clocks.

We do not test this or guarantee it will work in production. You may just want to toss in an EEPROM that the Atmel writes to then lets the FV-1 read.