Repository navigation
Conversation
AN619 only allows even integer MS6/MS7 ratios from 6 to 254. Several CLK6/CLK7 paths could write something else: - set_freq() below ~18.5 kHz clamped to 4 kHz (SI5351_CLKOUT_MIN_FREQ) instead of the CLK6/7 minimum, which ended with a ratio of 256 written to reg 90/91 as 0x00 and pllb_freq stored as 128 MHz (DEV-03). Clamp to 600 MHz / 254 / 128 (rounded up) and pick the smallest R divider that keeps the ratio <= 254. - set_freq_manual() on CLK6/CLK7 used the fractional MS0-5 math and wrote the low byte of P1 (87.4 MHz from 874 MHz wrote 0x00 instead of 10, DEV-15). It now writes the integer ratio, using R if needed, and returns 1 without writing anything if the chosen PLL has no valid even integer ratio for that frequency. - With the peer clock set, set_freq() checked the ratio before applying R and then wrote an uninitialised byte to reg 90/91 when the divider calculation failed. The ratio/R search is now done first and the call returns 1 without writes if no even integer ratio 6..254 exists. Odd ratios after R are refused too. - set_freq(0) on CLK6/CLK7 divided by zero with the peer set; it now returns 1 (there is no valid setting for 0 Hz).
set_freq() enables CLK0-CLK5 (reg 3) the first time each is set, but the CLK6/CLK7 branch never called output_enable(), so after reset() those outputs stayed disabled until the sketch enabled them (DEV-14). Do the same first-set enable for CLK6/CLK7 once the frequency has been accepted. No power-up write is needed: reset() already writes 0x0C to reg 22/23, as it does for CLK0-CLK5.
set_freq(), set_freq_manual() and multisynth_calc() clamped CLK0-CLK5 at SI5351_MULTISYNTH_MAX_FREQ / SI5351_CLKOUT_MAX_FREQ = 225 MHz, but the datasheet (Table 7) and AN619 (sec. 2, 4.1.3: DIVBY4 for 150 < Fout <= 200 MHz) give 200 MHz as the maximum (DEV-01). Requests above 200 MHz are now clamped to 200 MHz (DIVBY4, fVCO = 800 MHz) instead of up to 225 MHz (fVCO = 900 MHz). For example, set_freq(210 MHz) now gives 200 MHz. The public 225 MHz #defines are left unchanged so existing sketches that reference them still compile.
When pll_freq / freq is below 6 (for example set_freq_manual(140 MHz, 700 MHz)), multisynth_calc() clamps the frequency to pll_freq / 6 but kept the old integer part, so it wrote a ratio of 5, which AN619 does not allow (DEV-05). Set a = 6 together with the clamped frequency. The other out-of-range manual ratios (fractional 6..8, integer 7) are not changed here.
set_phase(CLK6/CLK7) wrote reg 171/172, which are reserved: only CLK0-5 have a phase offset register (165-170, AN619 sec. 6) (DEV-09). set_int(CLK6/CLK7) toggled bit 6 of reg 22/23, which is FBA_INT/FBB_INT, the PLLA/PLLB feedback integer-mode bit, not an MS6/7 bit. Setting it on a fractional PLL forces the PLL into integer mode (DEV-11). MS6/MS7 are always integer dividers and have no MSx_INT bit, so there is nothing for set_int() to do on those clocks.
set_pll_input(..., SI5351_PLL_INPUT_CLKIN) ORed clkin_div into reg 15 without clearing CLKIN_DIV[1:0] first (the clearing line was commented out), so a /2 setting followed by /4 left 11b = /8 (DEV-12). Replace the field when a PLL is switched to CLKIN. Switching a PLL to XO leaves the field alone, because the other PLL may still be using CLKIN.
init(SI5351_CRYSTAL_LOAD_0PF, ...) wrote XTAL_CL[1:0] = 00b to reg 183, which AN619 marks "Reserved. Do not select this option." (DEV-10). The chip has no 0 pF setting. Use the smallest valid internal load, 6 pF (01b), instead. The 6/8/10 pF settings are unchanged.
With the VCXO in use, AN619 (sec. 3.2, 7) requires the PLLB feedback denominator c to stay at 10^6. set_vcxo() set that up, but did not record that the VCXO was active or update pllb_freq. set_correction(), set_pll_input() and set_freq_manual()/set_freq() on PLLB later re-ran the normal PLL math with the stale pllb_freq (800 MHz). That dropped c = 10^6 (c = 1 when b = 0) and moved PLLB away from the VCXO frequency (DEV-08). set_vcxo() now records the pull range (new private member vcxo_pull) and pllb_freq. While it is set, set_pll(..., SI5351_PLLB) goes through set_vcxo(), so PLLB keeps c = 10^6 and VCXO_Param is recalculated for the new correction. reset() clears it, as it already cleared the VCXO registers. Public API unchanged.
In DIVBY4 mode the output is fVCO / 4 whatever frequency is requested, so set_freq_manual(225 MHz, 900 MHz) still gave 225 MHz after the 200 MHz clamp. Limit pll_freq to 800 MHz for DIVBY4 outputs so the output stays within the datasheet maximum. Also refuse (return 1, no writes) set_freq_manual() requests on CLK0-5 whose MS ratio is not one AN619 allows (4 via DIVBY4, 6, or 8 and up), e.g. 90 MHz from 600 MHz (6.667) or 100 MHz from 700 MHz (7). The check runs before the PLL write.
0 pF is not a supported XTAL_CL setting. Leave the crystal load at the chip's reset default (10 pF, 11b) rather than picking 6 pF, and document SI5351_CRYSTAL_LOAD_0PF as unsupported.
AN619 limits the feedback ratio to 15..90 and the VCO to 600..900 MHz. pll_calc() clamped the frequency for out-of-range ratios but kept the old integer part, so a 5 MHz reference wrote feedback ratios of 120 or 160 (DEV-13). Recompute a when it is clamped. If the reference cannot reach the VCO range with a legal ratio at all (below about 6.7 MHz or above 60 MHz after CLKIN_DIV), set_pll() and set_vcxo() now leave the PLL registers untouched instead of writing an illegal block. In-spec references (10-40 MHz) are not affected. Also mark SI5351_CRYSTAL_LOAD_0PF as unsupported in the header.
When a PLL was reprogrammed to a new frequency, outputs already running from it kept dividers computed for the old PLL frequency and drifted off frequency. Only set_freq()'s >100 MHz / re-plan path recalculated them, and only for CLK0-CLK5. Examples: CLK1 at 10 MHz on PLLB, then set_freq() on CLK6 re-plans PLLB to 874 MHz -> CLK1 at 10.925 MHz; set_pll(700 MHz) under a 10 MHz CLK0 -> 8.75 MHz; set_vcxo() with another output on PLLB. The existing recalc loop is moved into a private helper, pll_update(), which every PLL write now goes through (set_pll(), set_vcxo(), and so everything that calls set_pll(): set_freq re-plans, the >100 MHz path, the low-clock move, CLK6/7 PLLB planning, set_freq_manual(), init(), set_correction(), set_pll_input()). It stores the new PLL frequency and, if that changed, rewrites the MS (R, DIVBY4, integer bits) of every other output on that PLL whose frequency the library knows (clk_freq[] != 0), including CLK6/CLK7 (even-integer MS6/7 plus R, as in set_freq) and outputs set with set_freq_manual(). - Only recalculates when the stored PLL frequency changes, so steady- state tuning, set_correction() and set_pll_input() (same nominal VCO) add no I2C writes. set_freq()'s re-plan path forces the recalc as before. - Outputs with no valid ratio on the new PLL (AN619: 4 via DIVBY4 at exactly PLL/4, 6 exact, 8+; MS6/7 even 6..254 with R) are left as they are. - A PLL frequency outside the 600-900 MHz VCO range (pll_calc() clamps it, so the stored value is not what the chip runs at) does not trigger a recalc. - Still one PLL reset per operation, after all PLL and MS writes: DIVBY4 exits during the recalc are deferred (34c486c semantics) and set_freq_manual() / the CLK6/7 planning path issue the owed reset after their own MS write. - reset() clears clk_freq[] before reprogramming the PLLs, so it does not recalculate outputs it is about to turn off. - Moving an output with set_ms_source() or writing set_ms() directly still does not recalculate (no PLL frequency change). No public API change. New private member pll_update(); file-statics reset_owed, recalc_skip, recalc_force.
…_NO_DATA (0xFF) for no-data reads
|
Memory usage change @ 1c7199f
Click for full report table
Click for full report CSV |
6 tasks
Member
Author
|
Hardware verification, Si5351C (2026-10-27): all 12 steps of the v2.4.1 hardware test sketch passed on the Si5351C breakout (head |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Si5351Arduino v2.4.1: bug fixes rebased onto v2.4.0.
Changes
See the v2.4.1 changelog entry in README.md. Highlights:
set_freq_manual()ratio validationreset()/init()(Nullify spread spectrum #82, reset spread spectrum enable in init code #86)dev_status.LOSnow reports LOS_XTAL (reg 0 bit 3); new LOS_CLKIN/LOS_XTAL fields (need definition of error messages #85)get_i2c_error()(Library reports dev_status even when device is not present #74)set_correction()ppb formula/signVersion bumped to 2.4.1 in library.properties and library.json.
Verification
Known follow-ups (non-blocking)
*_MAX_FREQmacros still say 225 MHzset_freqcan return success without programming a PLL (e.g. invalid ref)set_freq_manualdoesn't reject a non-working divide-by-4 caseCloses #109