Hi TI,
When I use "PCLK from imager mode " for DS90UB913Q, Could PCLK be changed on the fly? or need some constraint?
Thank you!
Tony
This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
Hi Tony,
Yes, the PCLK can be changed during normal operation. However, the link will likely unlock and re-acquire lock with the new frequency. Depending on the frequency range change, you may also need to change frequency mode (with 12-bit interface: Low-speed for <50MHz, High-speed for 50MHz-75MHz). If the mode changes, a hardware reset is recommended.
Hi Ryan,
In my design, I change PCLK by reconfigrating imager's register through I2C. But ONCE PCLK is changed from 36MHz to 24Mhz, 913Q don't feedback ACK to 914Q from logic analyzer. At that time, imager feedback the ACK.
Thank you.
Tony
Hi Tony,
The I2C communication is dependent on the Lock state of the link - meaning that the embedded clock and data has been recovered from the forward channel (913 to 914) link. This link is dependent on the embedded clock, namely the PCLK signal. Other signals can be changed on the fly without disruption to the bidirectional link, but PCLK is necessary for continuous operation of the link. When PCLK stops, or changes frequency, the link is interrupted temporarily while the devices re-establish Lock.
Also, if the PCLK moves into another operational range (example: 10-50MHz then changes to 50-75MHz), then a change to the frequency mode and a device reset are needed.
So to summarize: Changing PCLK disrupts the link temporarily. I2C communication can be disrupted during that time.
Hi Tony,
In general, changing the PCLK frequency will cause the link to temporarily unlock/re-lock, which means that the bidirectional control channel is unavailable for the short time that LOCK=LOW. There isn't really a practical method for mitigating this. I suggest using the LOCK pin status or some other GPIO to check if bidirectional communication is available before starting I2C transactions.