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.

DAC63204: Daisy Chain SPI Mode not clocking

Part Number: DAC63204

Hi, we have a hardware board with 8 daisy chained DAC63204 devices that are wired as in the attached picture. Each SDO pin is tied to VCC via an 1k pull up resistor and daisy chained to the second device in the SDI line.

The clock speed is 500khz and spi mode 1.

First we set the SDO_EN bit to 1 and the we configure the register to output 3.3V on ch3 of the device. We tried to over ride by programming each individual device and the devices respond according to the firmware .

When in daisy-chain mode the devices never clock the data past the first device in the line. Are there any other specific requirements to make the daisy-chain mode work?.

As a note: in the data sheet is specified that SDO pin needs an pull-up resistor while the  SDI needs to be left floating, basically in the daisy-chain mode this being impossible.

The datasheet is also incorrectly label in the layout section as it follows:

  • Hi Moldovanu,

    You do need the pull up resistor on each SDO output. The output is open drain so the data will not clock out without a pullup resistor. The comment for the SDI pin is just saying you do not require a pullup/down on this pin. It does not need to be left floating.  

    Your schematic and scope screenshots are a little blurry so it is hard to read them. I think the schematic looks ok. It's good to know that the devices respond when being programmed individually. Are you enabling the SDO output on all 8 devices? I think you are sending the command 4 times on what I assume is the first SDI line (channel 1 on your scope), do you have a capture of the first SDO output being clocked out. It's possible that the second DAC is not receiving that command correctly. Does the output of the second DAC ever update when you talk to it via the daisy chain command?

    Thanks for pointing out the error in the layout diagram. I just forwarded it to our systems team. 

    Best,

    Katlynne Jones 

  • Hi, by now we made more test and it looks like the hardware board is working as expected.

    The problems seems to be that the SDO pin instead of passing the rest of the command after first ic is setting up is echoing the first issued command and also adding one extra bit to the echoed command.

    .

    These are the defined register and write and init functions that we use right now. Is there any firmware library that we could use to check if how we implement the fw is the right way?

  • Hi Moldovanu,

    We don't have any libraries for SPI communication. There are a few pseudocode examples for different DAC use cases in the datasheet and in some of our application notes, but I don't have any that use the DAC in daisy chain. 

    For daisy chain you need to leave CS low for 24clocks * the number of DACs in the chain. Each DAC will keep the last 24 bits it received after CS goes high. It looks like you are trying to send individual commands which may be the issue. 

    Best,

    Katlynne Jones

  • This is the output from the SDO of the first DAC after we enabled SDO pin by writing 0x05(FSDO EN and SDO EN) to 0x26 INTERFACE-CONFIG register. It appears that the next in the chain DAC echoes the last command received and adds one bit to and inverts the read/write bit. We are trying to send the SDO-EN command to all DACs in order to configure them to daisy-chain mode but because of the wrong/inverted bit echo we cant never send past the first DAC.

  • Hi Moldovanu,

    This timing diagram is correct. Each device will accept the last 24 bits of data it sees before the rising edge of chip select. In your screenshot, device 2 is seeing register 0x26, data 0x0005 and device 1 is seeing register 0x00, data 0x0000 (or a NOP command). 

    The data you are saying has an inverted bit is garbage data. 

    Are you sure that the SDO pin of device two is not enabled? You would have to pull chip select low again and initiate another command to check if device 2 starts clocking out data. 

    Best,

    Katlynne Jones