I designed a board where I’m using a SI5338C as a clock source to feed an FPGA and a transceiver.
The SI5338C is fed by a crystal oscillator of 12MHz at pins IN1 and IN2.
So far, I was able to write and read the chip’s register using the values on the register_map.h provided by the clock builder (V6.4) software. (see attached file)
For test purposes, I set up only one clock from the SI5338C as output (CLK0A).
The communication with the chip is done via I2C with an STM32F103C using the arduino IDE (see attached file).
The weird thing is that after flashing the microcontroller the input and output voltages from the crystal oscillator show a 0.3V.
Same thing with the output from the SI5338C (CLK0A) that shows a constant 0.3V.
I tried using the algorithm on the datasheet and the code on the Application Note AP428 but without success so far.
It sounds like you can get the device configuration to work (at least for a single output) via I2C, but when you try to flash the MCU (and I presume run your code) the device doesn't get properly configured?
I'm wondering if during the flashing process the I2C bus is being toggled and random registers in the Si5338 are being written. This could put the Si5538, or the I2C bus itself, in a non-functioning state. Do you have a way of monitoring the I2C bus during the flashing process, as well as when your code runs, to see if your I2C bus is quiet during the flashing process and/or if your code is able to appropriately drive the Si5338 I2C bus?
Thank you for your reply.
The attached file contains the values stored in the chip's registers after I2C communication with the µcontroller.
I'll check the values later one by one and let you know
I have checked the values obtained by reading the registers after executing the sketch and the values on the register_map file and the two sets of data are identical (considering the mask bits).
So the problem is not with the communication itself with the chip, but I guess it needs to be something wrong with the algorithm on the datasheet.
Finally, I solved the problem.
The issue was with my PC based oscilloscope. Once I changed it to another one, I am able now to see the output waveform.