• TI Thinks Resolved

DAC8771: DAC8771 stays in daisy chain after DSDO is set to 1

Intellectual 590 points

Replies: 25

Views: 143

Part Number: DAC8771

Hello,

I'm testing DAC8771 SPI communications before enabling/configuring any of the BBC arms (just AVDD=12.1V and enabling internal reference). 

I  select channel 0 (reg=0x03; data=0x0030) to disable the default daisy chain. Set reset configuration to enable internal reference (reg=0x2, data=0x0013).

All attempts to read from the device (e.g., status reg=0x0B or POR config reg=0x2) after power reset shows that the device is still in the daisy chain mode. (MISO is echo of last command delayed by 24 bit; and user bit is also 0). I also tried reset the device via register (reg=0x1; data=0x0001) at the startup.

Does the device defaults to  daisy chain mode when BBC is not enabled/configured (via 0x06 and 0x07)? or is there some other issues?

[BBC is disabled for now since VPOS and VNEG of the BBC will be used to power a analog switch (has 3.3V SPI) - not wired at the moment].

Note: I have been testing DAC8775 using the EVAL board, and noticed that I had to replace NOP=[0x00,0x00,0x00] with [0xFF,0xFF,0xFF] in the read command; testing with both MSP432 and Python at the test points of the EVAL board and was working. I tried both 0x00 and 0FF with DAC8771 but nothing works.

Thanks for your help.

  • Lasto,

    Please bear with us as most of the team is off for the Christmas holiday. You can expect a reply sometime next week.

    Kevin Duke
    DAC Applications Manager

  • In reply to Duke of DACs:

    Kevin,

    Thank you. No rush at all. Please take your time.

    Happy Holidays!

  • In reply to Lasto Roma:

    Hi Lasto,

    Sorry for the delay.

    Ultimately, I think you are just seeing the expected behavior of the device. Note that in figure 2 of the PDS we show that the readback data is always seen in the next command, and we use an example of an NOP being used.  

      This does not mean that daisy-chain mode is still active.  Enabling daisy-chain mode basically tells the device to continuously clock out the data after the first 24bits are shifted.  For example, if you had two devices in daisy-chain configuration and you clocked in 48 bits of data, the first DAC would latch the most-significant 24 bits and the second DAC would latch the least-significant 24 bits.  If you left the hardware the same and disabled daisy-chain mode and clocked in the same 48-bits, neither device would latch any data, as the they would see the frame as an invalid length.

    Thanks,

    Paul

  • In reply to Paul_Frost:

    Hello Paul,

    No problem.

    My apologies as I seem to have caused a confusion here. The key issue for me is that I can't read back data from the device registers (in the firmware). So, I started to look into the SPI signals.

    My issue is that my "Read Command" is reproduced as "Readback Data"  while sending the NOP commend in Figure 2 of the PDS.

    For example, if I set a register (status reg=0x0B or POR config reg=0x2 or user-bit) and try to read it back in the firmware I get the value of the "Read Command" command. I had no problem reading registers from the DAC8775-EVAL with same firmware (sending SPI commands via test points).

    I'm not sure but I believe that I have seen this behavior on DAC8775-EVAL GUI when it was out-of-box, i.e., if not all registers are configured (I had to fiddle with GUI settings to be able to read values from registers - e.g., status reg=0x0B).

    I agree with your note "Note that in figure 2 of the PDS we show that the readback data is always seen in the next command" But, I assume that you're referring to the previous "NOP" command showing as "GARBAGE" segment on SDO in Figure 2  of the PDS. 

    Please let me know if you'd need further information or clarification.

    Best regards.

  • In reply to Lasto Roma:

    Hi Lasto,

    To clarify, when you do the following:

    1. Write (0x040001) - write value 0x0001 to register 0x04

    2. Write (0x84wxyz) - issue a read command for register 0x04, where wxyz are "don't care bits"

    3. Write (0x000000) - issue a NOP command, the readback data should be present on SDO during this command.

    Are you saying in your post that during step 3, you just see the echo of the 0x84wxyz command rather than the expected "0x840001" (read command but with valid data)?

    Thanks,

    Paul

  • In reply to Paul_Frost:

    Hi Paul,

    Yes.

    I attached the SPI traces for the above three commands (Yellow=MOSI, Light Blue=CLK, Dark Blue=MISO, Red=CS all at 5V per division)

    [Note I invoked select BBC0 and Ch0 before issuing these write commands to ensure that "disable daisy chain" flag is set as bit 4 of register 0x03 per the PDS]. There is no supply going to the BBC at the moment.

    Thanks for your help. Please let me know if you need any additional information.

  • In reply to Lasto Roma:

    Hi Lasto,

    What value exactly are you writing to the register 0x03? Could you be enabling the CRC? That might just be causing the SDO pin to echo the response because no other command would be valid.

    Thanks,

    Paul

  • In reply to Paul_Frost:

    The that I send to 0x03 is 0x0030. The SPI trace is shown below (apology for resolution). The function call is also listed below.

    Thanks for your help. Please let me know if you'd need further data or tests.

     register = 0x03 and data=0x0030 

    void _dac_select_channel(uint8_t ch){  // ch={0,1,2,3}
    
        uint8_t first_ch_bit = 5;  //  for multi-channel DAC, the ch bits are {5,6,7,8}
        uint8_t disable_daisy_chain=1;
        uint8_t dsdo_bit = 4;
    
        uint8_t sel_ch = DAC_MULTI_CHANNEL? ch:0;
        if (sel_ch<DAC_CHANNEL_COUNT){
            uint8_t data[] = {0x00, 0x00};
            uint16_t dec = 1 << (first_ch_bit+sel_ch);
            if(disable_daisy_chain)
                dec |= 1 << dsdo_bit;
            uint8_t mask = 0xFF;
            uint8_t msb = (dec >> SSI_DATA_WIDTH) & mask;
            uint8_t lsb  = dec & mask;
            _spi_dac_write(DAC_CHANNEL_SEL_REG, msb, lsb);
        }
        // else invalid channel
    }

  • In reply to Lasto Roma:

    Any idea why the image is low resolution? Are you communicating at high frequency? 

    So after re-reading this thread, I think we may be on the wrong path.  This device only operates in daisy-chain mode, or the SDO pin is disabled.  There is no "disable daisy-chain" feature.  Though I admit that the wording for the DSDO bit is confusing.

    Let's try something.  Skip all configurations in your code.  Do not write to config register 0x03.  Just power on the device, and issue these three commands:

    1. Write (0x040001) - write value 0x0001 to register 0x04

    2. Write (0x84wxyz) - issue a read command for register 0x04, where wxyz are "don't care bits"

    3. Write (0x000000) - issue a NOP command, the readback data should be present on SDO during this command.

    You should see a read back.  

    I am concerned that when you write to 0x03, something is going wrong.  Given the noise scopeshot, I am wondering if the data is being mislatched, and you are actually setting the CREN bit.  This would enable the CRC and all other commands would be rejected by the device, though the device would still echo the rejected data on the next command.  In addition, if you were writing to 0x03 correctly, the SDO pin would be high-z and you would not see any response.

    Please give that a test.

    thanks,

    Paul

  • In reply to Paul_Frost:

    Hi Paul,

    I did reset HW Reset by taking pin 44 low (which is connected to 3.3V via 1K Ohm). Then executed the three commands.

    I included the code for the clock settings below (traces are 1us/div). I'm assuming the clock Polarity and Phase are OK. [The low resolution of the previous snapshot was due to settings of the desktop S/W]

    Please note that SPI coming from MSP432 via TI digital isolators are 3.3V, while DSO is 5V since I'm using internal VDD. 

    I also tried S/W reset and waiting for seconds before re-running the three commands - same result.

    Thanks very much for your help. Please let me know if you need additional tests.

    1. Write (0x040001) - write value 0x0001 to register 0x04

    Write (0x840110) 

    Write (0x000000) 

    Clock Settings

    g_systemClock = SysCtlClockFreqSet((SYSCTL_XTAL_25MHZ |
                                               SYSCTL_OSC_MAIN |
                                               SYSCTL_USE_PLL |
                                               SYSCTL_CFG_VCO_480), 120000000);
    // default ssi to support DAC after initialization
         MAP_SSIConfigSetExpClk(SSI2_BASE, g_systemClock, DAC_SPI_MODE,
                                    SSI_MODE_MASTER, (g_systemClock/40), SSI_DATA_WIDTH);