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.

DAC38RF84: DAC38RF84

Part Number: DAC38RF84

Dear TI Support Team,

I am reaching out regarding an issue we are experiencing with the DAC38RF84. The DAC unexpectedly stops outputting data. When this failure occurs, we observe in the ALM_SYSREF_DET register that either the PLL LOCK alarm or the ALM_SD1_PLL alarm is asserted (set to '1').

The success rate of the DAC functioning correctly varies significantly depending on the specific hardware unit and the ambient temperature. For example:

We have a hardware unit that works flawlessly at 25°C but completely stops working when the temperature drops to 5°C.

Conversely, we have another unit that fails to operate at all, even at 25°C.

Device configuration, PCB layout, and the FPGA bitstream are identical across all tested units.

We are currently unable to pinpoint the root cause of this inconsistent behavior. Could you please provide some guidance on what might be triggering these PLL alarms and causing the data output failure?

Thank you in advance for your assistance.

  • Hey Jiri, 

    Sounds like you are using the DAC PLL based off reading the status of the PLL_LOCK field. Can you provide more information on your PLL settings? In addition can you read back the PLL loop filter voltage when the PLL is locked and functioning? Just read PLL_LFVOLT field in register 0x06. 

    Regards, 

    Matt

  • Hey Matthew,

    Thank you for the suggestion. I read back the PLL_LFVOLT field in register 0x06 and the value matches the table in the Start-up sequence section of the datasheet, which is expected for room temperature operation. Registrer 0x06 = 0x2f82 =>
    TEMP data = 47 (decimal) and LFVOLT = 4 (decimal). 

    I also noticed another issue on page 0x09 = 0x0001 : the Clock Divider Alarms 1 Register (address 0x6D) occasionally reads 0x0404 instead of the expected 0x0000, and in this case the DAC also stops working.

    Our DAC configuration is:

    0x09 0x0000
    0x00 0x5860
    0x02 0xffff
    0x03 0xffff
    0x09 0x0004
    0x0a 0x7c03
    0x0c 0xa002
    0x0d 0xf000
    0x1b 0x0000
    0x23 0xffff
    0x24 0x1001
    0x34 0x0000
    0x35 0x0018
    0x3d 0x0088
    0x3e 0x0909
    0x3f 0x0000
    0x09 0x0001
    0x0e 0xffff
    0x0f 0xffff
    0x10 0xffff
    0x11 0xffff
    0x1c 0x0000
    0x1d 0x0000
    0x24 0x0030
    0x27 0x8888
    0x28 0x0330
    0x29 0x0000
    0x2a 0x0000
    0x2b 0x0000
    0x2c 0x0000
    0x2d 0x1fff
    0x2e 0x1fff
    0x2f 0x0000
    0x32 0x8400
    0x33 0x8400
    0x30 0x0000
    0x4f 0x1c60
    0x50 0x0000
    0x51 0x00ff
    0x52 0x00ff
    0x53 0x0100
    0x54 0x8e60
    0x5c 0x0002
    0x5f 0x0123
    0x60 0x4567
    0x64 0x0000
    0x65 0x0000
    0x66 0x0000
    0x67 0x0000
    0x68 0x0000
    0x69 0x0000
    0x6a 0x0000
    0x6b 0x0000
    0x6c 0x0000
    0x09 0x0004
    0x3c 0x8a29
    0x31 0x0401
    0x32 0x070f
    0x33 0x4030
    0x0b 0x0002
    0x09 0x0000
    0x01 0x5880
    0x09 0x0001
    0x0a 0x8810
    0x0c 0x27f2
    0x0d 0x0001
    0x17 0x0000
    0x19 0x0003
    0x1e 0x3333
    0x1f 0x3333
    0x20 0x2933
    0x21 0x9999
    0x22 0x9999
    0x23 0x2b99
    0x6d 0x0000
    0x25 0x3700
    0x4a 0x0f03
    0x4b 0x0a01
    0x4c 0x0f03
    0x4d 0x0300
    0x4e 0x0f0f
    0x09 0x0004
    0x3b 0x9802

    Best regards,
    Jiri

  • Is it possible the DAC is losing its clock at one point or another? A disruption in clock can cause errors like this to arise.