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.

DAC53204: Problem configuring 2nd DAC in daisy chain when DACs power-up in 3-wire SPI mode.

Part Number: DAC53204

Hi,

My board has two DACs with the SPI connected in a daisy chain. We are unable to program the 2nd DAC in the chain. There are 3 relevant pieces of information:

  • a) The DACs power up in 3-wire SPI mode (i.e daisy chain is disabled, i.e. SDO pin disabled) which means that they only latch the first 24 SDI bits after SYNC goes low.
  • b) My goal is to configure both DACs into 4-wire SPI mode (i.e. daisy chain enabled) by enabling the SDO pin on each DAC. The command to enable SDO is 3 bytes: [0x26,0x00,0x01].
  • c) Texas Instruments acknowledges in AN-2001 that after SS goes low, the first bit transmitted out of the DAC's SDO is always 1, and we have confirmed this behavior on DAC53204.

So we try to program the DACs in 4-wire SPI mode and quickly run into an issue programming the second DAC, as described below:

  1. We issue an SPI write [0x26,0x00,0x01] to the first DAC. This successfully enables the SDO pin on the first DAC. So far so good.
  2. We then issue a no-op SPI write [0x00,0x00,0x00] to the first DAC. This should cause the first DAC to echo its previous command [0x26,0x00,0x01] onto SDO towards the second DAC. However, since the first bit on SDO is replaced with a 1, the first DAC actually echos the command [0xA6,0x00,0x01] to the second DAC and the second DAC fails to enable its SDO pin because it received the wrong command.

You might suggest that we send the command twice in a single transfer, i.e. transfer 6 bytes instead of 3, so that the last 24 bits seen by the 2nd DAC are correct, but the 2nd DAC will only latch the first 24 bits because it powered up in 3-wire SPI mode.

How can we ensure that the first 24 bits seen by the 2nd DAC are [0x26, 0x00, 0x01] if the 1st DAC always outputs a 1 on the first SDO bit? (which converts the 0x26 into 0xA6)

  • Hi Philippe, 

    Typically the last 24 bits of the frame are latched regardless of if SDO is enabled or not. Have you tried writing the SDO enable again along with a no-op in one 48-bit frame? I believe we have had customers use daisy chain with this device. I will also try it out when I am back in the lab. 

    Can you share a screenshot of the SDO enable write to the second DAC? You can share both when you use the echo and when you use the 48-bit frame. 

    Best,

    Katlynne Jones  

  • Hi Katlynne,

    Thanks for the quick response. I believe we've tried enabling SDO on the 2nd DAC with a 48-bit frame but we will try it again to confirm and take a screenshots of 24-bit and 48-bit frames to the 2nd DAC.

    Concerning which bits are latched during a frame, if I refer to the DAC53204 datasheet, it states:

    "By default, the SDO pin is not enabled (three-wire SPI). In the three-wire SPI mode, if the access cycle contains more than the minimum clock edges, only the first 24 bits are used by the device."

    "The daisy-chain operation is also enabled with the SDO pin. [...] In four-wire SPI mode, if the access cycle contains multiples of 24 clock edges, only the last 24 bits are used by the device first device in the chain."

    Phil

  • We are reviewing now.  The US holiday weekend will delay the response.

  • Thanks Paul. My screenshots may be delayed as well due to limited hardware access.

  • Hi,

    Here are the screenshots for 2 different test cases, both of which failed to enable the SDO pin on the 2nd DAC.

    Test #1

    SPI transfer #1 to 1st DAC: [0x26,0x00,0x01]. This enables SDO on the 1st DAC.

    SPI transfer #2 to 1st DAC: [0x00,0x00,0x00]. The 1st DAC echos its previous message on SDO with first bit replaced by 1, that is: [0xA6,0x00,0x01]. The 2nd DAC fails to enable its SDO pin.

    Test #2

    SPI transfer #1 to 1st DAC: [0x26,0x00,0x01,0x26,0x00,0x01]. This enables SDO on the 1st DAC (which latched the first 3 bytes).

    SPI transfer #2 to 1st DAC: [0x26,0x00,0x01,0x26,0x00,0x01]. The 1st DAC outputs the following on SDO: [0xA6,0x00,0x01,0x26,0x00,0x01]. The 2nd DAC latches the first 3 bytes and fails to enable its SDO pin.

  • Hi Philippe, 

    I'm seeing the same issue. The echo has '1' in MSB, and second DAC won't accept the second set of 24 bits without SDA already being enabled. 

    I'm asking the design team if there is any way around this. The requirement may be that you need to enable the SDO pins for all of the devices in the chain and save this setting in the NVM before being able to use daisy chain. I will let you know what I hear back

    Best,

    Katlynne Jones 

  • Hi Katlynne,

    Thanks for testing it yourself and confirming the behavior. We've resorted to that workaround for now, that is enabling the SDO pin on all devices, one by one, by using blue wires to directly access the SDI of each DAC in the chain and saving the settings to NVM, but this is quite a tedious and manual process. I'm hoping there is a better solution.

    Phil

  • Hi Phil,

    Glad to know that works at least.

    Still waiting on a response. I will update you when I hear back. 

    Best,

    Katlynne Jones 

  • Hi Katlynne,

    I was just wondering if there was any news on this topic.

    Phil

  • Hi Phil,

    Sorry for the delay. I had a meeting with the designer to discuss the issue a few days after my last response. They didn't design this exact module and didn't have an immediate answer for me, so they were going to investigate any work arounds. I asked them for a follow-up and should hear back by tomorrow (they are in India and on an opposite time zone from us). I expect they got busy with other things. 

    Based on the meeting, it looks like the behavior you observed is expected in the design and I don't think there's going to be a way to get around that to talk to the second device before its SDO has been enabled. I'll keep pushing for an answer from the designer either way and let you know asap. 

    Best,

    Katlynne Jones 

  • Hi Katlynne,

    Ok, thank you for the update and for following up on the issue.

    If it were possible to buy the DACs already configured in daisy-chain mode then that would work for us but I haven't seen an option to purchase with custom NVM settings.

    Phil

  • Hi Phil,

    They got back to me that they weren't able to find a workaround. I'll push to make it more clear in the datasheet that SDO needs to be enabled on all devices before using daisy chain. I wasn't even aware of this caveat, so thank for being patient as we worked through it together.  

    We do not sell custom/pre programmed NVM devices. Are you using any of the smart features in this DAC (function generation, slew rate control, etc)? If not, I can help you find another part that will support daisy chain out of the box. All of the devices in the smart DAC family will have the same behavior. 

    Best,

    Katlynne Jones

  • Hi Katlynne,

    I don't believe we are using any of the smart features. If there is a replacement part that supports daisy-chain out-of-the-box, NVM, and at least 3 output channels, that would be great! Otherwise, we'll have to modify our design to use the I2C bus instead of the SPI bus.

    Phil

  • Hi Phil, 

    The smart DAC family of devices (DACx3x04) are the only option if you require the NVM.

    Best,

    Katlynne Jones 

  • Hi Katlynne,

    Ok, thanks for letting me know. I guess our only option is to switch to I2C then so that we can access all the DACs on the bus. We'll move forward with this, thank you for all your help.

    It does seem a bit strange though that the daisy chain feature would be broken in all smart DACs. Surely someone must have gotten this to work. Either we discovered a real oversight or we're missing a key step.

    Phil