Skip to content
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

Frequency Set Failure with Sequential Setting of Clk0 and Clk1 #39

Open
va7ta opened this issue Mar 17, 2017 · 3 comments
Open

Frequency Set Failure with Sequential Setting of Clk0 and Clk1 #39

va7ta opened this issue Mar 17, 2017 · 3 comments
Assignees
Milestone

Comments

@va7ta
Copy link

va7ta commented Mar 17, 2017

Frequency set failures occur when I try to change both Clk0 and Clk1 in a single command.
It only appears to happen when initially Clk0 is set < 100 MHz and Clk1 is set > 100 MHz.
If Clk0 is initially set higher than Clk2 it doesn't happen. This one was tough to get a handle
on and took me 30 test cycles until I think I finally understand when it happens.

I don't believe it happens as long as only one clock frequency is changed at at time.

Apparently if one of the frequencies is >100 MHz it must be lowered first to avert the failure.

Failure only seems to happen when Clk0<Clk1 to start with.

examples:
With initial MHz setting clk0=60, clk1=145; then clk0=160, clk1=45; then clk1 is set OK but clk 0 is not set to 160 first attempt, but sets OK on second attempt.

With initial MHz setting clk0=160, clk1=45; then clk0=45, clk1=145; OK first attempt.

Test Sequences for your replication:

step Clk0, MHz clk1, MHz Comment
Set Result Set Result
1 60 60 145 145 OK
2 160 60 145 145 No Change OK
3 160 60 45 45 Clk0 did not change Clk1 OK
4 160 160 45 45 OK - 2nd try
5 160 160 145 45 No Change OK
6 60 60 145 145 OK
7 160 60 145 145 No Change OK
8 160 60 45 45 Clk0 did not change Clk1 OK
9 160 160 45 45 OK - 2nd try
10 145 145 60 60 OK
11 145 145 160 60 No Change OK
12 45 45 160 160 OK - 1st try both clks
13 145 145 60 60 OK
14 45 45 160 160 OK - 1st try both clks
15 60 60 145 145 OK
16 60 60 45 45 OK
17 160 160 45 45 OK
18 160 160 145 45 No Change OK
19 160 160 45 45 OK
20 160 160 145 45 No Change OK
21 160 160 45 45 OK
22 60 60 145 145 OK
23 160 60 145 145 No Change OK
24 160 60 45 45 Clk0 did not change Clk1 OK
24 160 160 45 45 OK - 2nd try
25 60 60 145 145 OK
26 160 60 45 45 Clk0 did not change Clk1 OK
27 160 160 45 45 OK - 2nd try
28 60 60 145 145 OK
29 160 60 45 45 Clk0 did not change Clk1 OK
30 160 160 45 45 Clk0 did not change Clk1 OK
31 60 60 145 145 OK

@NT7S
Copy link
Member

NT7S commented Mar 17, 2017

Thank you for the report!

@NT7S NT7S self-assigned this Mar 17, 2017
@NT7S NT7S added this to the v2.1.0 milestone Mar 17, 2017
@gartnl
Copy link

gartnl commented Jul 12, 2018

I ran into this too and just a thought: if you change sequentially and the clk1 is > 100 and the new clk0 >100 clk0 will not be set because only one clk can be above 100 MHz. After setting clk1 below 100 in your first attempt and setting clk0 in your second a frequency >100 is not a problem anymore.
I solved it by ordering frequencies from low to high and sending them in that order.
eg if the original setting for 3 clk's is clk0>80,1>60,2>156 and the new settings are 0>143,1>70,2>90 I will send 1>70,2>90,0>143.

@frohro
Copy link

frohro commented Mar 21, 2019

I don't know if my problem is the same as this one, but maybe. I find that if I set CLK0 and then CLK2, CLK0 becomes unstable (while CLK1 is fine), but if I set CLK0 and CLK1, both clocks are stable. The two oscillators are 100 Hz apart in frequency. My PCB is using CLK0 and CLK2, so this is inconvenient. I should mention that I'm using an older version of the library as well, because in newer versions I could not change the frequencies as fast as I could with the older libraries about a year ago. I should try to see if this has perhaps been resolved, but didn't have time today.

Any ideas what might be happening?

Thanks,

Rob

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants