8
\$\begingroup\$

I'm using the Si5351A-B-GM clock generator with the NX5032GA-25.000M-LN-CD-1 (25 MHz, 8pF) crystal. The fragment of the schematic is shown below (the rest of the schematic omitted for clarity):

schematic

Description of the schematic

The crystal (25 MHz) is connected across XA and XB and there are 3 outputs:

  • SYS_CLKIN0 (25 MHz, 1.8V)
  • UNCK (3.072 MHz, 3.3V)
  • TM0_CLK (96 kHz, 3.3V)

These outputs are connected to other ICs which are omitted for clarity.

The power supply is connected according to the datasheet:

  • the core supply (VDD) is 3.3V
  • VDDOA (output voltage for CLK0 and CLK1) is 1.8V
  • VDDOB (output voltage for CLK2 and CLK3) is 3.3V
  • the unused supplies (VDDOC, VDDOD) are connected to VDD as mentioned in the datasheet

The SDA and SCL pins are connected to the I2C bus and are programmed by a computer.

The A0 pin is the LSB of the I2C address (in this case '0').

OEB is 'output enable', and GND means that the output is enabled (as per the datasheet).

SSEN enables/disables the "spread spectrum" feature. In this case it's held high, which means it's enabled, but only if a particular clock output is configured to use the "spread spectrum" feature - I have configured all outputs to not have this feature (i.e. it's disabled).

The physical layout of the PCB is shown below:

PCB layout

For scale, the clock generator is 2.7 x 2.7 mm or 0.1 x 0.1 inches (without the pins).

Description of the problem

The actual generated clock signals are faster (higher frequency) than expected, and they are faster by a factor of approx. sqrt(2) - I'm not sure if this is just a coincidence or it actually is related to the sqrt(2).

For example, when I check UNCK (which should be 3.072 MHz) with oscilloscope, the average measured period is around 230 ns and should be ~325.5 ns. 325.5 / 230 ≈ 1.4152, which is suspiciously similar to sqrt(2) ≈ 1.4142.

This is true for all 3 clock outputs (all of them are faster by the same factor). I haven't checked the other 2 with oscilloscope, but I've set up timers on the DSP (SHARC) they're connected to and they seem to be off by the same factor.

What I've tried so far

  • Changing / removing the crystal. After changing the crystal (to another one of the same model), the problem still persists. After removing the crystal, the clock generator produced a ~500 kHz signal instead of 3.072 MHz, which indicates that the crystal actually gets connected to the clock generator.

  • Changing the clock generator load capacitance - the configuration software for the clock generator allows to change the in-built load capacitance to 0pF, 6pF, 8pF or 10pF. I've tried all values, but the result is the same.

  • Changing crystal to a different model: I also tried ECS-250-20-5PXDU-F-TR (also 25 MHz), which has 20pF load capacitance (so technically is incompatible with the clock generator, which only allows up to 12pF), but the result was also the same.

Edit 1

I'm using the Adafruit MCP2221A board to program the clock generator from PC via I2C. I copy the register dump from the PC GUI clock configuration tool, and paste it to a script which I then run to send the data to the clock generator.

The content of the GUI tool dump looks like this (I'm using the option to generate C code, because this makes it the easiest to copy the data to the script):

#ifndef SI5351A_REVB_REG_CONFIG_HEADER
#define SI5351A_REVB_REG_CONFIG_HEADER

#define SI5351A_REVB_REG_CONFIG_NUM_REGS                61

typedef struct
{
    unsigned int address; /* 16-bit register address */
    unsigned char value; /* 8-bit register data */

} si5351a_revb_register_t;

si5351a_revb_register_t const si5351a_revb_registers[SI5351A_REVB_REG_CONFIG_NUM_REGS] =
{
    { 0x0002, 0x53 },
    { 0x0003, 0x00 },
    { 0x0004, 0x20 },
    { 0x0007, 0x01 },
    { 0x000F, 0x00 },
    { 0x0010, 0x0F },
    
    // the rest of the registers, 61 in total
};

#endif

Then I convert it to a PowerShell script like this:

MCP2221CLI.exe -i2cW="02,53" -slave7=60
MCP2221CLI.exe -i2cW="03,00" -slave7=60
MCP2221CLI.exe -i2cW="04,20" -slave7=60
MCP2221CLI.exe -i2cW="07,01" -slave7=60
MCP2221CLI.exe -i2cW="0F,00" -slave7=60

# the rest of the registers, 61 in total

MCP2221CLI.exe is the "MCP2221 Command Line Interface", which can be downloaded from the Microchip's website.

I also tried to make the register address 16-bit in the script (because that's how it's written in the C code), so e.g. this: MCP2221CLI.exe -i2cW="0002,53" -slave7=60 instead of MCP2221CLI.exe -i2cW="02,53" -slave7=60, but it didn't change anything.

After each execution of MCP2221CLI.exe (61 in total), there is a message that the write was successful, so it looks like it's sending the data correctly.

Edit 2

As Rahmany pointed out, I wasn't configuring the clock generator according to the programming procedure in the datasheet.

However, even after following the procedure, the result is still the same.

Below is the new script, modified to follow the procedure:

# Disable Outputs
# Set CLKx_DIS high; Reg. 3 = 0xFF

MCP2221CLI.exe -i2cW="03,FF" -slave7=60

# Power-down all output drivers
# Reg. 16, 17, 18, 19, 20, 21, 22, 23 = 0x80

MCP2221CLI.exe -i2cW="10,80" -slave7=60
MCP2221CLI.exe -i2cW="11,80" -slave7=60
MCP2221CLI.exe -i2cW="12,80" -slave7=60
MCP2221CLI.exe -i2cW="13,80" -slave7=60
MCP2221CLI.exe -i2cW="14,80" -slave7=60
MCP2221CLI.exe -i2cW="15,80" -slave7=60
MCP2221CLI.exe -i2cW="16,80" -slave7=60
MCP2221CLI.exe -i2cW="17,80" -slave7=60

# Set interrupt masks
# (see register 2 description)
# This register is only used in Si5351C,
# so in theory should have no effect here.

MCP2221CLI.exe -i2cW="02,53" -slave7=60

# Write new configuration to device using
# the contents of the register map
# generated by ClockBuilder Pro. This step
# also powers up the output drivers.
# (Registers 15-92 and 149-170)

MCP2221CLI.exe -i2cW="02,53" -slave7=60
MCP2221CLI.exe -i2cW="03,00" -slave7=60
MCP2221CLI.exe -i2cW="04,20" -slave7=60
MCP2221CLI.exe -i2cW="07,01" -slave7=60
MCP2221CLI.exe -i2cW="0F,00" -slave7=60

# the rest of the registers, 61 in total

# I'm also configuring the B7 register (crystal load capacitance),
# even though it's outside of the 149-170 range. But since it was in
# the configuration generated by the GUI tool, and it's quite
# important, I'm assuming it should be here.


# Apply PLLA and PLLB soft reset
# Reg. 177 = 0xAC

MCP2221CLI.exe -i2cW="B1,AC" -slave7=60

# Enable desired outputs
# (see Register 3)

MCP2221CLI.exe -i2cW="03,00" -slave7=60

\$\endgroup\$
12
  • 2
    \$\begingroup\$ How did you program the registers? Did you make your custom driver, or simply uploaded a register dump made by the PC GUI tool to set up the chip? \$\endgroup\$
    – Justme
    Commented Dec 13, 2022 at 17:00
  • \$\begingroup\$ @Justme I'm using the Adafruit MCP2221A board to program the clock generator from PC via I2C. I copy the register dump from the GUI configuration tool, and paste it to a script which uses MCP2221CLI.exe (MCP2221 Command Line Interface) to send this data to the clock generator. To better show what I mean, I updated the question to add the GUI dump and how I convert it to a script. \$\endgroup\$
    – jbz
    Commented Dec 14, 2022 at 0:53
  • \$\begingroup\$ Since it's scaled by \$ \sqrt(2) \$, it's not a simple bit shifting problem. Does your oscilloscope have a serial communication decoder or do you have a logic analyser? You can see what the MCP2221 really sends to the clock generator. \$\endgroup\$
    – Rahmany
    Commented Dec 14, 2022 at 15:30
  • \$\begingroup\$ Also, is the I²C peripheral correctly configured in 7-bit address mode? Try running it at 100kbps if that's not the case. \$\endgroup\$
    – Rahmany
    Commented Dec 14, 2022 at 15:32
  • \$\begingroup\$ Did you respect the programming procedure of the Si5351A-B-GM? (datasheet, under Section 6.1, p. 20). Sorry for the spam. \$\endgroup\$
    – Rahmany
    Commented Dec 14, 2022 at 15:40

1 Answer 1

0
\$\begingroup\$

I suspect that the enabled spread spectrum is shifting the frequency in an unsuspected/uncontrolled manner.

SSEN enables/disables the "spread spectrum" feature. In this case it's held high, which means it's enabled, but only if a particular clock output is configured to use the "spread spectrum" feature

This is incorrect in indicating a logical AND functionality, when it is actually a logical OR functionality.

AN619 application note describes the spread spectrum enable differently than is described in the question.

enter image description here

So spectrum spreading is enabled on all channels regardless of the individual control register settings.

To disable spectrum spreading on all channels, SSEN must be tied low, and, the individual channel SS enable bits must be set to DISABLED as well.

I suspect that root-2 coincidence is just that, but digging deeper may find a relationship to maintaining the power spectral density if the spread spectrum system was enabled properly.

Many of the registers' bits are unknown at reset. They need to be set to a known state soon after reset.

\$\endgroup\$

Not the answer you're looking for? Browse other questions tagged or ask your own question.