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.

DAC80504: SPI Configuration

Part Number: DAC80504

Hi,

I read the post concerning the DAC80504 SPI Write/Read Operation :
https://e2e.ti.com/support/data-converters-group/data-converters/f/data-converters-forum/956441/dac80504-dac-80504-interfacing-problem-with-tm4c129encpdt-using-spi

However some timings remain unclear,

1) For a write operation, the SPI described in datasheet seems to be a hybride of CPOL=0, CPHA=1 and CPOL=1, CPHA=0.
Does SCLK has to be set to '0' at least 7ns before CS falling_edge ?
"tCSIGNORE = SCLK falling edge to CS ignore" : I don't understand the meaning of the definition related to the figure 62 of the datasheet.
Figure62.png

Or can it be as following (exemple of write data 0xFF00 to addr 0x02.
SPI_WRITE_02_FF00.png

The first SCLK edge seen when CS is low is a falling_edge ?


2) For read operation : On the figure 63, on the second part of the diagram during "ANY COMMAND" process, we see that the SCLK seems to be already at '0' after the CS falling_edge, however does the timing is the same for tCSIGNORE.

Figure63.png

The first edge seen during the second part of the read process is thus a rising_edge (for data update [see FSDO = '0' in CONFIG Register]) ?

Or can it be as following (exemple of read addr 0x01).

SPI_READ_01.png

Best regards,
Antoine

  • Antoine,


    I checked with one of the designers on your question and I did find a few answers.

    1. The tCSIGNORE is timing to ensure that the SCLK falling edge near /CS falling edge is not mistaken as the first SCLK falling edge. There is some internal timing to both /CS and SCLK that could cause problems if the two lines are near coincident. You want to make sure the SCLK rise is larger than this timing value.

    2. Certainly, the diagram isn't very clear on your point. The quick answer is that yes, you could set the read in the way you describe:

    SPI_READ_01.png

    When the /CS goes low, the bit 23 appears on the SDO pin when the SCLK is high. So if SCLK is high when /CS goes low, the data appears on SDO when /CS goes low. The read should be active at the last SCLK falling edge of the previous frame.


    Joseph Wu

  • Hi Joseph,

    Thank you for your reply,

    I'm not sure to have well understood your answer to the point 1.
    I'll try to explain how I understood your explaination, can you validate/unvalidate the comprehension ?

    While the /CS signal is high the SCLK can be any state, however, before the falling edge of /CS, if a falling edge of SCLK occurs, it has to be at least 7ns (tCSIGNORE) before the falling edge of /CS not to be considered as the first falling edge of the SPI transaction (red arrow). This way the first SCLK while /CS il low is correctly detected (green arrow).

    Best Regards,
    Antoine

  • Hi Joseph,
    I forgot to precise that I set the configuration of FSDO in CONFIG Register to '0'.


    Thus I also want to check if this solution is possible : 
    Write : SCLK is low in IDLE and first rising edge is ignored by DAC80504 ?

    Read : In first part (same as principle as write : SCLK is low in IDLE and first rising edge is ignored by DAC80504 ?)
    In the second part, the first edge seen by DAC80504 is a rising, this way figure 63 with FSDO is respected

    Best Regards,
    Antoine

  • Antoine,


    Yes, I think you've described it correctly, but I did change your diagram. The falling edge of SCLK should be at least 7ns before the falling edge of /CS. This timing is needed to prevent any race condition between /CS and SCLK. The diagram should look like this:

    As for the following post, with FSD0=0 and the SCLK low in idle, this method is fine. However, the rising edge isn't ignored by the device. The output data appears on SDO when the SCLK rises high. If SCLK is idling high, then the data appears on SDO when the /CS goes low. The SCLK high immediately sets the data on SDO.


    Joseph Wu

  • Hi Joseph,

    Thank you for correcting my diagram, I totally agree you on this point.

    For your second answer on my second reply, I think we also both agree. Just for precision I wanted to say that (with FSD0=0 and the SCLK low in idle), the first rising_edge in the first transaction part (command) has no impact on the detection of the R/W command bit on SDI and thus the first falling edge on SCLK.

    At the moment, I do not have the hardware platform to test my driver, do you advise me to leave the topic open (in case of problems during my tests) or to close it (as This resolved my issue and maybe re-open later) ?

    Best Regards,
    Antoine

  • Antoine,

    Yes, I think we're in agreement on how the SPI works. 

    I'll just close this thread. If something comes up, you're free to open up a new thread, as the topic will likely be different. If you want to add something to this particular thread, there's a pretty good amount of time before it gets locked. 

    Again, feel free to post if you come up with something else.

    Joseph Wu