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.

DAC3482: abnormal floor noise and spur after power up

Part Number: DAC3482

Hi,

Below shows the normal floor noise and output signal of DAC3482 in this board.

But sometimes after power-up of the board, the floor noise of DAC3482 is much bigger and there is many spurs near the output signal. When this happens, it can be solved by tuning Reg_0x24. Could you pls suggest any method that I can try to avoid this issue? What is the possible root cause of this issue? There is another DAC3482 with same schematic and register setting in this system which is programmed later after power-on. I didn't find the same issue in this later one.

Thanks.

  • Hello Jerry,

    The config 0x24 (or config36 register) is to tune the setup/hold time of the LVDS bus. The setup/hold time can be adjusted through internal LVDS data or dataclk delays to match the external timing. The minimum setup/hold time needed for each delay is shifted based on the config36 setting. The customer will need to measure each LVDS pin with respect to DATACLK to ensure good setup/hold time is met. Otherwise, there will be bit errors

    the customer may use IO pattern test to fine tune their setup/hold time.

    the setup/hold time is defined based on industrial standard:

  • Thank you, Kang.

    After the issue happened, I can fix it by configuring Reg_0x24. However, I initialized DAC3482 with the same Reg_0x24 value I used to fix the issue, and repeatedly power-on/off the board, issue still happened once. At this moment, I can also change Reg_0x24 to another value to fix it again. So I don't think it is really due to the delay time.

    I found the customer didn't follow the sequence of Table 10. LVDS DATA and CLK in Step 25 were actually provided before Step 1. My question is, after configuring Reg_0x24, does LVDS interface interrupt then recover? If the interrupt and recover do exist, it may match the sequence and solve the problem.

    I attached all the registers' values here.

    config.txt
      
    
      Dac3482Write(0x02, 0x80f2, chipNo);
        Dac3482Write(0x00, 0xf288, chipNo);
        Dac3482Write(0x01, 0x0000, chipNo);
        Dac3482Write(0x03, 0xf001, chipNo); 
        Dac3482Write(0x04, 0xffff, chipNo);
        Dac3482Write(0x05, 0x0660, chipNo);
        Dac3482Write(0x06, 0x0000, chipNo);
        Dac3482Write(0x07, 0xffff, chipNo);
        Dac3482Write(0x08, 0x0000, chipNo);
        Dac3482Write(0x09, 0xa000, chipNo);
        Dac3482Write(0x0a, 0x0000, chipNo);
        Dac3482Write(0x0b, 0x0000, chipNo);
      
        Dac3482Write(0x0c, 0x07ff, chipNo); //update from 0x05a6 to 0x07ff by zhangwencheng 2012.05.05 ¬������
        Dac3482Write(0x0d, 0x07ff, chipNo); //update from 0x05a6 to 0x07ff by zhangwencheng 2012.05.05 ¬������
         
        Dac3482Write(0x0e, 0x05a6, chipNo);
        Dac3482Write(0x0f, 0x05a6, chipNo);
        Dac3482Write(0x10, 0x3000, chipNo);
        Dac3482Write(0x11, 0x0000, chipNo);
        Dac3482Write(0x12, 0x0000, chipNo);
        Dac3482Write(0x13, 0x0000, chipNo);
        Dac3482Write(0x14, 0x5555, chipNo);
        Dac3482Write(0x15, 0x3a55, chipNo);
        Dac3482Write(0x16, 0x0000, chipNo);
        Dac3482Write(0x17, 0x1f40, chipNo);
        Dac3482Write(0x18, 0x205f, chipNo);
        Dac3482Write(0x19, 0x10f4, chipNo);
        Dac3482Write(0x1a, 0x4820, chipNo);
        Dac3482Write(0x1b, 0x0800, chipNo);
        Dac3482Write(0x1c, 0x0000, chipNo);
        Dac3482Write(0x1d, 0x0000, chipNo);
        Dac3482Write(0x1e, 0x1818, chipNo);
        Dac3482Write(0x1f, 0x8882, chipNo);
        Dac3482Write(0x20, 0x2200, chipNo);
        Dac3482Write(0x22, 0x1b1b, chipNo);
        Dac3482Write(0x23, 0x001f, chipNo);
        Dac3482Write(0x24, 0x0000, chipNo);
        Dac3482Write(0x25, 0x5a5a, chipNo);
        Dac3482Write(0x26, 0x5a5a, chipNo);
        Dac3482Write(0x27, 0x5a5a, chipNo);
        Dac3482Write(0x28, 0x5a5a, chipNo);
        Dac3482Write(0x29, 0x5a5a, chipNo);
        Dac3482Write(0x2a, 0x5a5a, chipNo);
        Dac3482Write(0x2b, 0x5a5a, chipNo);
        Dac3482Write(0x2c, 0x5a5a, chipNo);
        Dac3482Write(0x2d, 0x0000, chipNo);
        Dac3482Write(0x2e, 0x0000, chipNo);
        Dac3482Write(0x2f, 0x0000, chipNo);
        Dac3482Write(0x30, 0x8000, chipNo);
        Dac3482Write(0x7f, 0x0001, chipNo);
        Dac3482Write(0x1f, 0x8884, chipNo);
        Dac3482Write(0x1f, 0x8886, chipNo);
    
    
        Dac3482Write(0x00, 0xf287, chipNo);
        Dac3482Write(0x05, 0x0000, chipNo);
    	if( (Dac3482Read(0x05,chipNo)& 0x2000) == 0x2000)
    	{
    		printf("DAC FIFO IN pointer collision\n");
                    Dac3482Write(0x00, 0xf287, chipNo);
    	}
    	else
    	{
    		Dac3482Write(0x00, 0xf287, chipNo);
    	}
    
    

  • Hi Jerry,

    System timing may change depending on the DVDD and other supply current and voltage. Upon configuration of the device and fully powered up, the DVDD current increases and may draw more current. This may cause more DCR drop on the supply line and may violate our minimum voltage requirement. This may also impact the input timing. They will need to measure the power supply pins at the DAC3482 device pins to ensure proper voltage is applied. They need to account DCR.

    Please advise the result of the IO pattern test. We cannot proceed without it

    Sequencing of the FRAME signal to properly reset the FIFO and other logic is critical. Please refer the customer to read through the following document on the importance of synchronization. It is possible the device is not properly synchronized. Adjusting the delay simply shifted the timing of the logic to make the error marginal again. 

    Please ask the customer to carefully review the recommended sequence and apply it. Having reviewing the register config file is only a small piece of the puzzle to this problem.

    Please do me a favor and make sure all registers files is compatible format with the DAC3482 GUI. Please try to load the config file to the DAC3482 GUI to see if it can be loaded correctly. 

  • Hi Jerry,

    I am closing this ticket as I have not yet heard from you for a couple of days. You can always submit a new ticket or reply back if needed. Thanks

    -Kang