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.

DAC71416: is connected to FPGA, and we are using 50 MHz as SCLK, but DAC is not configuring

Part Number: DAC71416

DAC 71416 is connected to FPGA, using 50 MHz as SCLK, but DAC is not configuring, the supply voltage given to VIO is 3.3 V,

and we are matching the timing requirement also but it is not getting configured. But it is configured with SCLK of frequency 25MHz.

Thanks in advance.

  • Hi Kabilan,

    To clarify, with the exact same register commands you can control the device at SCLK=25MHz, but at 50MHz it does not work?

    Can you read the registers you are writing? If you try just updating a single channel, and reading back the result - does it work?

    Can you share a schematic? Can you share an oscilloscope capture of a write command that fails?

  • https://drive.google.com/drive/folders/1U2JYyFgTkz79wPBD_rLyRY0790zYYjPm?usp=sharing

    I shared the read and write operation of DAC screen shot for your reference,  data_mem in screenshot is the device id but we need to right shift the value by two.

    In spi write the cs_n setup time should be minimum 15 ns , but we kept 30 ns in the screen shot but the dac is not configured.

    if the dac should be working in 50 Mhz SCLK , what should be the VIO supply voltage and current  should be given to DAC?

    thanks in advance.

  • Hi Kabilan,

    I am not seeing an obvious issues with your timing, can you try adding additional delay on the CS high time? 

    In addition, if you send singular commands separated with a longer delay, does it improve things? For example, if you still use 50MHz but add 300µs delay between commands does the configuration work? I am mostly concerned about violating the TDACWAIT command.  The timing diagram does not sufficiently describe the limitations, but if you are issuing sequential DAC register updates you would need to insert this delay as a tCSHIGH delay.

    Thanks,

    Paul

  • Sorry, I did not mean to mark this as "TI thinks resolved".