• State Resolved
  • Locked Locked
  • Replies 20 replies
  • Answers 3 answers
  • Subscribers 47 subscribers
  • Views 3560 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

DAC7716: Daisy-chain readback SPI problem

Pieter Van Trappen
Prodigy 100 points
Part Number: DAC7716

Hello, we're using the DAC7716 in a design where 5 DACs are daisy-chained, i.e. there's a common clock and CSn and successive MOSI/MISO are linked. There is no problem performing daisy-chain mode writings, as indicated in the datasheet Fig. 2. The daisy-chain readback doesn't work however, although all readback timings from Fig. 3 are respected. There is no specific figure for *daisy-chain* readback mode in the datasheet and moreover it is not working as expected (many zeros returned in the 120-bit vector) which makes us wonder if it is indeed supported? Since the data is shifted out when CSn is high I don't see why it wouldn't work (theoretically). Thanks for looking into this.

  • 0
    TI__Mastermind 46290 points
    Hello Pieter,

    I apologize for the delay due to some internal events. My colleague and I will be looking into this. You can expect an update within 24 hours. Thank you for your patience.
  • 0 in reply to Kevin Duke
    TI__Genius 14220 points
    Hi Pieter,

    Thanks for your query. We have actually never tested the read-back in daisy-chain mode as I understood from the internal team. However, there doesn't seem to be any prohibition in the design as well to stop it from functioning. If you want us to analyze your SPI sequence, please send the scope shots. I will have it checked by the design team and let you know if there is anything wrong in principle.

    Regards,
    Uttam Sahu
    Applications Engineer, Precision DACs
  • 0 in reply to Uttam Sahu
    Prodigy 100 points

    Hi Uttam, thanks for looking into this. I agree since I don't see any functional prohibition of the daisy-chain read-back to work either. We'll get you some waveform screenshots shortly. Regards, Pieter

  • 0 in reply to Pieter Van Trappen
    TI__Mastermind 46290 points
    Hi Pieter,

    Any update on this topic?
  • 0 in reply to Kevin Duke
    Prodigy 100 points

    Hi Kevin, sorry for the late supply but we didn't have time until recently to continue the analysis and then we wanted to understand if properly before posting. For your information we have 5 DACs daisy-chained (A->B->C->D->E), please have a look at the card page [1] and schematics [2]. We had 2 people looking at it separately that arrived to the same conclusions. We have a custom VHDL implementation for the SPI master.

    Please have a look at the attached screenshots and the Tektronix wave files (*.csv) [3]. When we're writing all goes well and we see the shifted commands on the sdo line from the last DAC (i.e. E). We're iterating over all 4 DAC-channels so 4x 120 bit (120=5*24-bit/channel). When we're performing successive write/read cycles we notice however that only DAC E is replying the correct channel read-back, the other data is all zeroes. This is easily visible on the attached screenshots. We're wondering if the DAC has possibly a state-machine that after a read-back command and 24-bit reply continues to send zeroes only? We're quite certain that all timing constrains are met and we have slowed down the spi clock significantly for our analysis.

    Do you have a possibility to check the daisy-chain readback in your labs? Thanks in advance for your help.

    [1] www.ohwr.org/.../wiki

    [2] edms.cern.ch/.../1

    [3] https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/73/SPI_5F00_readback_5F00_problem.7z

  • 0 in reply to Pieter Van Trappen
    TI__Genius 14220 points
    Hi Peiter,

    I am looking into your files. Will also discuss with the internal team and get back with my analysis soon.

    Regards,
    Uttam
  • 0 in reply to Uttam Sahu
    TI__Genius 14220 points
    Hi Pieter,

    As I mentioned earlier, this is an untested feature. Hence, I will need to test itexplicitly in order to provide you any suggestion. As I don't have multiple EVMs for this device with me right now, I am ordering them. I will test the daisy-chain once I get them in my lab. Please bear with us till then.

    Regards,
    Uttam
  • 0 in reply to Uttam Sahu
    Prodigy 100 points
    Hello, any progress on this problem? Do you have the possibility to verify the design files (HDL?) as well of this IC in case the EVMs are not available? Thanks in advance.
  • 0 in reply to Pieter Van Trappen
    TI__Genius 14220 points
    Hi Pieter,

    I have already placed the order for the EVMs. I will verify the functionality on them. It is very difficult to test it on the design files as this is an old device.

    Sorry for keeping you waited.

    Regards,
    Uttam
  • 0 in reply to Uttam Sahu
    Prodigy 100 points

    Hello, any update on this? It is becoming a blocking problem for our product. Thanks in advance.

  • 0 in reply to Pieter Van Trappen
    TI__Genius 14220 points
    Hi Pieter,

    I am very sorry for the delay. I got the EVMs. Currently working on your problem. Will let you know about the results soon.

    Thanks a lot for your patience.

    Regards,
    Uttam
  • 0 in reply to Uttam Sahu
    TI__Genius 14220 points
    Hi Pieter,

    I have been working on your problem for last few days but unfortunately couldn't find any solution till now. I will convey my findings by end of this week.

    Thanks a lot for your patience.

    Regards,
    Uttam
  • 0 in reply to Uttam Sahu
    Prodigy 100 points
    Hello Uttam, thanks for the info. Were you able to reproduce the problem?
  • 0 in reply to Pieter Van Trappen
    TI__Genius 14220 points
    Hi Pieter,

    I was trying to solve the daisy-chain read-back problem for last couple of weeks. I was able to reproduce the problem you had stated and was trying to see if there is any workaround. But unfortunately I have not been able to get any success in that. I am trying to involve other people as well in solving this but lately I am unable to get much support due to the holiday season. I will let you know about my findings in the first week of Jan.

    Thanks a lot for your patience.

    Regards,
    Uttam
  • 0 in reply to Uttam Sahu
    TI__Genius 14220 points

    Hi Pieter,

    Soon after writing my previous post, I could get hold of a digital designer and we could find a workaround for the problem. The steps are as follows (for 3 DACs in daisy-chain):

    1. Write in daisy-chain as usual per datasheet 

    2. Send read command for the first DAC and NOP for others in daisy-chain

    3. Send NOP command for all in the daisy-chain and parse MISO line for data from first DAC

    4. Send read command for the second DAC and NOP for others in daisy-chain

    5. Send NOP command for all in the daisy-chain and parse MISO line for data from second DAC

    6. Send read command for the third DAC and NOP for others in the daisy-chain

    7. Send NOP command for all in the daisy-chain and parse MISO line for data from third DAC

    Please note that the steps 2, 4 and 6 can be interchanged.

    Due to some custom implementation in the design, we need to go through the above steps to perform a proper read-back of all DACs in the chain. I understand that this is a multiplication of the steps and in your design, you will need 10 SPI cycles to read 5 DACs, instead of 2 cycles.

    Please find the scope shots below:

    First write (0x05, 0x33, 0x30, 0x05, 0x22, 0x20, 0x05, 0x10, 0x10): This is the value I am going to read back:

    Second Write (0x04, 0x7F, 0xF0, 0x04, 0x7F, 0xF0, 0x04, 0x7F, 0xF0): To make sure I am not just reading back the data from the shift register that has not been updated from the DAC registers:

    First Read Command (0x00, 0x03, 0x3C, 0x00, 0x03, 0x3C, 0x85, 0x00, 0x00): 

  • 0 in reply to Uttam Sahu
    TI__Genius 14220 points

    First NOP (0x00, 0x03, 0x3C, 0x00, 0x03, 0x3C, 0x00, 0x03, 0x3C): Read-back first DAC data now:

  • 0 in reply to Uttam Sahu
    TI__Genius 14220 points

    Second Read (0x00, 0x03, 0x3C, 0x85, 0x00, 0x00, 0x00, 0x03, 0x3C):

  • 0 in reply to Uttam Sahu
    TI__Genius 14220 points

    Second NOP (0x00, 0x03, 0x3C, 0x00, 0x03, 0x3C, 0x00, 0x03, 0x3C): Read-back data from second DAC:

    Third Read (0x85, 0x00, 0x00, 0x00, 0x03, 0x3C, 0x00, 0x03, 0x3C):

    Third NOP (0x00, 0x03, 0x3C, 0x00, 0x03, 0x3C, 0x00, 0x03, 0x3C): Read-back data from the third DAC here:

    I think your issue is resolved now. Please let us know if you are facing any further problems.

    Regards,

    Uttam

  • 0 in reply to Uttam Sahu
    Prodigy 100 points
    Hello Uttam, thanks for testing and the detailed information. It's a pity that you can reproduce the fault, this confirms something is broken in the design. The workaround you proposed was one we already had in mind but it will increase significantly the read-out latency (> x5 since we have 5 DACs daisy-changed). The workaround was never tested from our side so good to see it confirmed. Your help has been much appreciated!
  • 0 in reply to Pieter Van Trappen
    TI__Genius 14220 points
    Hi Pieter,

    The main reason why the design has not implemented it straight is that the daisy read-back is not part of the spec and over the years we never got any customer request to implement it. Hence, the fundamental tendency of a designer is to tune the design in order to optimize other specs. As you must be knowing, it's always a trade-off among the specs in a design and the low-priority and unspecified ones always get impacted.

    That was also the reason why I took some time to figure the workaround as the implementation is device specific. I was aware of the latency problem while proposing the solution to you, but there was no other option for this device. Hope, you should be able to proceed with this limitation. Please let us know in case you need any other support. I would suggest you to get the design reviewed by us in future in case you are taking some decisions based on some assumptions that are not clear in the datasheet. As the devices are developed and tested to the datasheet specs, it is very difficult to say whether a functionality is possible or not if not specified in the datasheet.

    Again, thanks a lot for using our device and pointing out this problem. We are now trying to add this requirement in our future designs.

    Regards,
    Uttam