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: DAC63204 / DAC63004 SPI rules

Part Number: DAC63204
Other Parts Discussed in Thread: DAC63004, , ENERGIA, DAC53204, ADS7953

Hi,

I want to "marry" DAC with NVM and multi-channel ADC on one SPI interface.

For this one of them should respond on first data package (? bit) and other should ignore it and respond to last data package (may be of different length) during the same /CS. If I will find devices, working this way, everything should work well. Today I have such an arrangement with not TI parts and with no NVM in DAC. SAR ADC locks first 8-bit and responds immediately (during the same /CS) with result, and DAC waits until the end (rising) of /CS and takes last packet before that as a command (even with NOP option).

I also need that ADC and DAC will be in complete silent mode during inactive /CS.

Now, with new DAC devices, with NVM inside, I would like to upgrade functionality and get the similar performance, but those DAC-s are responding to the first x-bits after the /CS was applied and it ruins me all fun :-).

This is from DAC63204/DAC63004 data sheet, page 27: "If the access cycle contains more than the minimum clock edges, only the first 24 bits are used by the device."

Need advise, please.

  • Hi Pavel,

    This would be easily accomplished if you were able to use an I2C interface instead of SPI, the DAC63204 can also use I2C. It is true that the DAC63204 will ignore the bits in the SPI cycle exceeding 24 bits. I do not believe we have any DACs with NVM that take the last packet before the rising edge of /CS like you describe.

    Is it possible for you to add an inverter to one of the /CS inputs of either the DAC or the ADC? If you only have one GPIO available for a chip select then you would write to one device while the /CS from the processor is high, and the other device while the /CS from the processor is low. 

    Can you also explain what you mean by "ADC and DAC will be in complete silent mode during inactive /CS". I am unsure what silent mode is. 

    Best,

    Katlynne Jones

  • Hi, Katlynne

    If I will use inverter on /CS, like you proposed, there will never be a situation that no one is selected. Looks not good, at least it is against SPI logic. But nice try, I like it.

    When I say completely silent, I mean that when /CS is not asserted (high), nothing moves inside ADC and DAC, no clocks and nothing else. I need a completely synchronous system, under SPI /CS control, doing nothing by itself. It is because it is a part of very sensitive detector and should note make any noise.

    Thank you

  • Hi Pavel,

    Another suggestion is to find an ADC that supports daisy chain mode. The DAC63204 supports daisy chain when the SDO pin is enabled. The clock polarity and phase of the ADC will need to be the same as the DAC63204. The clock speed for the DAC63204 in daisy chain mode is lowered to about 1MHz. 

    This application report (link) describes using daisy chain mode to communicate between multiple of the same DAC, but if the SPI sequences match then you could daisy chain a DAC and ADC together. 

    Best,

    Katlynne Jones

  • Katlynne, you are a genius!

    What a brilliant idea.

    Let’s imagine that DAC will receive the 64-bit communication with one /CS, what data bits out of those 64 bits will appear at SDO pin, will there be all 64 bits, or only those that are redundant for the device after it has accepted the command?

     Thank you very much

  • In case that a DAC shifts all its received data bits out as they were arrived, then it will not work, since the ADC accepts first 8-bits at its SDI as a command.

    But the idea is elegant.

    Thank you

  • Hi Pavel,

    I am verifying one thing with the design team just to be sure before I write my response. I should hear back from them by tomorrow.

    Thank you,

    Katlynne Jones

  • Hi, Katlynne

    OK, will be waiting for your answer.

    One more question - what are all differences between DAC63004 and DAC63204?

    Thank you

  • :-) and one more, please.

    How could I get (for free or buy) any kind of hardware (cable with interface translator, e.g. USB to SPI) with a simple software GUI, which will allow me to control the DAC directly from my laptop?

    Thank you

    Pavel Margulis

  • And one more (:-)) - in a current source mode, does it know both, to sink and source the output current?

  • Since this SmartDAC may live its own life, i.e. make a sine or triangle waves, or slew signals at its output with predefined timing not related to SPI clock and after this SPI clock is stopped, it means that it has some timing reference signal inside. It also performs the NVM write operation much slower than SPI communication works.

    Does this internal clock signal stays alive all the time or only when I activate these "independent" modes?

    As I mentioned before, I need the device to be completely silent between SPI transmissions.

    Thank you

  • Hi Pavel, 

    I haven't gotten an answer back from the design team on my previous question. I'll also ask them about the internal clock signal and hopefully they give me an answer by tomorrow. The device can source or sink up to 250uA of current in IOUT mode. The DAC53204 has a GUI made specifically to update the DACx3204 registers. The GUI uses a TI Launchpad to generate the SPI/I2C signals from the computer. I don't think TI has a GUI for USB to SPI/I2C, but you can create simple C or energia (similar to arduino) code to generate the SPI signals from the Launchpad. In addition you could create a simple GUI specific to your needs using the GUI Composer tool and a TI Launchpad. If you are not interested in any of that then you do a google search to find some more options. I found this one by Diolan (link here) that comes with a GUI and labview library.

    Thank you,

    Katlynne Jones

  • Hi Pavel,

    In addition, one of my colleagues recommended the Total Phase Aardvark for USB to SPI at the link here.

  • Hi Ketlynne

    I just recap the still open questions, for your attention, please:

    1. Let’s imagine that DAC will receive the 64-bit (or any other length of more than it needs for itself) communication with one /CS, what data bits out of those 64 bits will appear at SDO pin, will there be all 64 bits, or only those that are redundant for the device after it has accepted the command?
    2. What are all differences between DAC63004 and DAC63204, except power consumption?
    3. Since this SmartDAC may live its own life, i.e. make a sine or triangle waves, or slew signals at its output with predefined timing not related to SPI clock and after this SPI clock is stopped, it means that it has some timing reference signal inside. It also performs the NVM write operation much slower than SPI communication works. Does this internal clock signal stays alive all the time or only when I activate these "independent" modes? As I mentioned before, I need the device to be completely silent between SPI transmissions.

    Hope to get answers and explanations for those above.

    Thank you very much for your help

    Pavel Margulis

  • Hi Pavel,

    I apologize for the delay. I've received a response from the design team on the outstanding questions. 

    1. The DAC needs 24*N total bits in daisy chain mode and then the DAC will accept the last 24 bits in the chain. The DAC will expect to get a total of 24*N number of clocks. Any frame with clock count not multiple of 24 will be considered as invalid frame and it will be ignored. With a total of 64 bits, if possible I'd suggest writing an extra 8 bits of dummy data (something that will be considered an invalid input to the ADC) before writing the 24 bits necessary to update the DAC so there is a total of 24*3 bits. 
    2. The only difference between the DAC63004 and DAC63204 is the power consumption. They are otherwise functionally the same.
    3. I have confirmed that the oscillator is dynamically switched on/off as per functional needs. So, if no function generation feature is used, the device with automatically turn-off the oscillator in between SPI frames.

    Best,

    Katlynne Jones

  • Hi Katlynne,

    Re: your answer 1 above.

    The data sheet (page 28, paragraph 7.5.1) states following:  .

    • So, it reacts to FIRST 24-bits in the session and don't ignore the frame, which is not aligned to 24 bits.
    • You got from the product designers (I believe) that it reacts to the last 24-bit in the session and wants a frame aligned exactly to N*24 bits.

    So, where is the truth?

    And when it recognized its data and takes it for its response, what data shows up at the SDO pin, the whole data and only the remainder after it removed its own 24/8 bits?

    Thank you

  • Hi Pavel,

    In daisy chain mode the first DAC in the chain should accept the last 24-bits written. The designer let me know that this device supports daisy chain and the device accept the last 24-bits. Let me confirm with the team why the datasheet mentions the opposite. Maybe this is a typo in the datasheet.

    The data is clocked out as described in this section of the DACx1416. The total number of bits needs to be 24*N so the first 24 bits are completely clocked out via the SDO pin of the DAC, and then the remaining 24bits are accepted by the DAC. You can write 8 bits for your ADC, 16 bits of dummy data, then 24 bits for the DAC. The DAC only accepts the last 24 bits of data in it's shift register when CS becomes high, you would send the data meant for your ADC first and it will shift out on the SDO pin of the DAC. 

    Best,

    Katlynne Jones

  • Hi Katlynne,

     So to summarize and to clarify finally.

     The DAC SPI interface wants two conditions to be fulfilled (a logic AND):

    1. The quantity of clocks, associated with a single CS negative pulse, should be an integer multiple of 24. In any other case it will be completely ignored.

    2. The last 24 bits before CS rise will be taken for interpretation as a command by this rising edge of CS.

     Is this correct and were clarified with chip design team?

    Thank you very much

  • Hi Pavel,

    Yes your two points are correct when the device is in daisy chain mode. I heard back about the datasheet confusion, and there should be two sections:

    1. Daisy Chain Mode
      1. Clock count has to be exactly 24*N else the frame is rejected.
      2. Device interprets the last 24 bits of the frame.
    2. Stand-alone mode (this is what's described in the datasheet)
      1. For clock count > 24, first 24 clock are considered and the frame is accepted.
      2. No need for clock count to be multiple of 24 any number >24 is legal.

    Daisy chain mode is enabled when the SDO pin is enabled (SDO_EN bit is set to 1). Thank you for your patience. 

    Best,

    Katlynne Jones

  • Hi Katlynne

    Thank you very much for your help.

    Sincerely

    Pavel Margulis

  • Hi Pavel,

    Not a problem, please let me know if you have any additional questions.

    Best,

    Katlynne Jones

  • Hi Katlynne,

    Still have a question. You was so kind and instrumental that I am forwarding it to you.

    As you may see above, my goal is to use a DAC63204/63004 and some multi-channel SAR ADC on the same SPI interface. Both devices will be used for control and diagnostics, and will be operated occasionally (I mean that they will not be running periodic conversions).

    I am currently looking on 16-ch 12-bit ADS7953. As I understand from its data sheet, it works with no internal clock, other than SCLK, and reacts to the first 16 bits of the SPI frame.

    So, I imagine following:

    • /CS, SCLK and SDI (host SPI MOSI) signals are connected to both devices in parallel
    • SDO of the ADC is connected to host SPI MISO and goes back to SPI host
    • SDO of the DAC is not connected and left open :-(
    • DAC is set in the daisy chain mode
    • first 16 bits of each frame control ADC, and last 24 bits of it control DAC

    I see some questions and invite you to help me to find answers. You may transfer this issue into TI application note.

    • will this arrangement work?
    • first, after POR I have to command the DAC to go into daisy chain mode, in order to make it reacting to the last 24 bits of each frame and not to the first 24 bits. How to do this, I mean
      1. how to recognize that there was a POR event of the DAC located remotely, and
      2. how to instruct the DAC to work in daisy chain mode if after POR both DAC and ADC are looking on the first bits of each frame?
    • is this possible to get back to host also an SDO signal from DAC? It is tempting to have the ability of reading data back from DAC. As I understand this ADC doesn't support the daisy chain mode, isn't it?

    Thank you for your help.

    :-)

  • If you have any suggestion about other ADC in this system, which will work smoothly with DAC63204, I will appreciate it very much.

  • Hi Pavel,

    In daisy chain mode the DAC needs 24*N total clocks and then it will accept the last 24 bits. Daisy chain mode is enabled by writing a 1 to the "SDO_EN" bit in the INTERFACE-CONFIG register. It would make most sense to connect the SDO of the DAC to the SDI of the ADC so that the first command to enable the DAC SDO is not seen by the ADC. Once the SDO output of the DAC is enabled then future commands will be clocked out on the SDO pin which will be input to the ADC. 

    The SDO_EN setting can be saved in the NVM the first time you program it. On future POR the DAC will automatically power on in daisy chain mode.

    I do not see a way to readback from the ADC and DAC without a second CS. 

    Best,

    Katlynne Jones

  • Hi Katlynne,

    Thank you for the alternative way to connect those two devices on the same SPI.

    1. Still, do you think that my configuration will not work for any reason?
    2. Is this possible to recognize that there was a POR event since last check?
    3. I can't find detailed information about the DAC63204 SDO pin behaviour in daisy chain mode, in particular, what data will it output on all clocks out of 48, e.g. will it just shift out the whole input data, copying to itself appropriate 24 bits for execution, or it will shift out only the remainder data, after it cuts out its 24 bits from the stream, or other combination? And also, will at the beginning of the frame, it will output at SDO the data from the previous frame, or each /CS clears the output shift register of SDO? It also should look like differently for write and read operations. The detailed timing diagram and few sentences of explanation would help a lot.
    4. Active clock edges for DAC63204 (falling for SDI, and rising for SDO) and ADS7953 (rising for SDI, and falling for SDO) are opposite, so most probably, I will need to put an invertor on the clock of one of them, no matter in what configuration will they work. Otherwise, you will propose other way to align this issue ... Regarding this issue, may the SClk of the DAC63204 start and end with (and be between SPI frames at) logic 1? The Fig. 6-2 and 6-3 in the data sheet don't prohibit it, they only state timing constrains related to the first falling edge of the SCLK. Are you agree, or may be you will clarify this issue with design team, please?
    5. Could you also clarify with design team of ADS7953 following questions:
      1. will it react to the command at its SDI at a FIRST 16 clocks only, in a long SPI frame and ignore other data?
      2. I plan to operate it with about to 115 KHz at SCLK (115 KBaud). Since it is based on capacitive DAC and SCLK frequency doesn't limited from below in its data sheet, I am wondering - will it still operate within its specs at such a slow SCLK?

    Please, respond to all my questions.

    Thank you

    Pavel Margulis

  • Hi Pavel,

    1. In your current configuration the ADC will see the same data as the DAC. When you send the command to the DAC to enable the SDO the ADC will also see this. This is ok if the write command will not be a valid command to the ADC. 
    2. Not that I am aware of without using an voltage monitoring external circuit. The VDD must be less than 0.7 V for at least 1 ms for the POR to occur in the DAC so that would need to be monitored if you expect this supply condition to happen.
    3. Read is not meant to be used in daisy chain mode. In daisy chain mode the SDO pin of the first DAC is meant to be connected to the SDI of the next DAC in the chain and so on. The SDO pin of one DAC in the chain could be connected back to the controller, and in that case the read command would be the same as given in the datasheet. There is no "daisy chain read". When the 48 data bits are clocked out, the first 24 bits will be clocked out on SDO. See this app note on daisy chaining DACs (link).
    4. Yes I agree, when CS goes low, the next falling edge should be at least 18ns later. Then there should be a total of 24*N clocks. The SCLK can idle high as long as the SPI mode is selected to shift data on the rising edge and have the device clock the data on the falling edge.  
    5. This is a question for our ADC team. I will try to loop them into this thread. 

    Best,

    Katlynne Jones

  • Hi Pavel,

    5a. The timing diagram shows that SDI can be high or low after the 16-bit word. Therefore, it is my understanding that anything after the 16 bits should be ignored. 

    5b. The device should be able to operate with that low of an SCLK. Be cautious that some performance degradation may be present at that low of an SCLK. I recommend supplying an SCLK of 200kHz or greater for more reliable performance. 

    Regards,

    Aaron Estrada

  • Hi Aaron,

    What performance may degrade and how much?

    Thanks

    Pavel Margulis

  • Hi Pavel,

    Unfortunately, it is hard to say since the device was not characterized for that SCLK frequency and we do not have any data for a 115kHz SCLK. 

    Regards,

    Aaron Estrada

  • Hi Aaron,

    I am not asking to guaranty it, It is about a direction of what to expect and how much, a clue / feeling. 

    Anyway, the design team knows the device the best way.

    You didn't said it in the data sheet (probably you have to), so at least give me a feeling of what to expect.

    I am going to measure DC voltages for diagnostic purposes, so harmonics and other dynamic staff is out of my interest.

    In general, I am interested in DC accuracy.

    Thank you for your help

    Pavel Margulis

  • HI Pavel,

    Understood. With a slower SCLK, there is a possibility of some leakage in the internal sample/hold capacitor. When this happens the conversion result may get compromised. If there is leakage present, I suspect that offset error can be impacted.

    Regards,

    Aaron Estrada

  • Hi Aaron,

     Unfortunately, this is what I’ve suspected.

    • Is this possible that you will check it on the EVM of the ADC? I simply don’t have it.
    •  Any advise about how to reduce this possible effect upfront, at the schematic design and PCB layout stage of the project, please. Like will some of the following change the risk’s probability:
    •      use a buffer between MUX and ADC (currently, I planned just to shoot them)
    •      use opamp drivers at all inputs (currently, I use opamps with 100 Ohm in series and Schottky diodes for overvoltage protection)
    •      do not put ground plane below ADC input / MUX inputs pins
    •  anything else?

     Thank you

  • Hi Pavel,

    The potential leakage from the internal sample/hold capacitor is due to the ADS7953 using SCLK as the conversion clock. Some other SARs have an internal conversion clock and use SCLK to shift the data out. Because of this, I don't believe any schematic or PCB layout will affect the potential leakage and this is a caveat of the ADS7953.

    Regarding the EVM, I currently don't have one available and will need to see if any colleagues have a board I can use. I will keep you updated on this. 

    Regards,

    Aaron Estrada

  • Hi Aaron,

    As I understand, you are talking about the leakage of a charge on sampling capacitor of the DAC during the (10*12)=120 us between the acquisition end and end of conversion, when SCLK is 100 KHz.

    I am trying to imagine where this leakage current is flowing.

    I would like to learn your opinion about my way of thinking as below:

    • I am measuring the DC voltage, so fast changes of it are not expected and also not interesting to me
    • the conversion happens when input MUX is disabled (as I think)
    • in this state, the sampling capacitor into the SAR ADC sees the disabled MUX and the comparator's input of SAR ADC
    • the charge on the sampling capacitor, acquired during acquisition stage, leaks into the comparator input and from the MUX output
    • in case that both are made with the similar/same wafer process, as they are, since they are on the same die, I may expect that those two leakage currents will be of the similar magnitude.

    Is there a reason to think in other way?

    Thank you

    Pavel Margulis

  • Hi Pavel,

    Your initial statement about the sampling capacitor leakage is correct.

    Regarding the bullet points, you can find my comments in red:

    • I am measuring the DC voltage, so fast changes of it are not expected and also not interesting to me
    • the conversion happens when input MUX is disabled (as I think)
      • The conversion period starts on the falling edge of CS and not when the mux is disabled. 
    • in this state, the sampling capacitor into the SAR ADC sees the disabled MUX and the comparator's input of SAR ADC
      • This is the case if there is no buffer between the MUX output and the input to the ADC. 
    • the charge on the sampling capacitor, acquired during acquisition stage, leaks into the comparator input and from the MUX output
      • This is correct
    • in case that both are made with the similar/same wafer process, as they are, since they are on the same die, I may expect that those two leakage currents will be of the similar magnitude.
      • There still may be some device to device variation in regards to the potential leakage of the sampling capacitor. However, I generally see that devices from the same lot will behave similarly. 

    As for the EVM, I am not able to get a hold of one any time soon. I will still keep looking but I don't believe we have one readily available. 

    Regards,

    Aaron Estrada