• State TI Thinks Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 46 subscribers
  • Views 1235 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

DAC8750: Daisy-Chain Mode problem

Michael Fischer41
Prodigy 40 points
Part Number: DAC8750

Hello,

 we have a problem with the Daisy Chain mode of the DAC8750.

We have 4 DAC's in daisy chain mode and it works well but after some days or weeks the output of the 3 dasy-chain DAC's are hold on the last value.
The first DAC works without any problem.

The DAC's are updated every 100ms. ( control and data register )

Best regards,

  Michael Fischer

  • 0
    TI__Mastermind 46290 points
    Hello Michael,

    Could you share the schematic for this design? Perhaps if only the DAC page(s) are shared, could you also describe anything else that may be on the same SPI bus as the daisy-chained DACs?
  • 0 in reply to Michael Fischer41
    Prodigy 40 points
    The 477 7122E2 is the schematic of the power unit.
    The 477 7122E1 is the schematic of the CPU.
    The *E6 ist the schematic of the current output.
    The E7 ist a schematic of a digestor circuit. The digestor use the same SPI.

    PS : The digestor works without any problem and the fist current output works without any problem.
  • 0 in reply to Michael Fischer41
    TI__Mastermind 46290 points
    Hello Michael,

    This likely comes without surprise since the system does work as expected for some period of time, but I do not see any issues with your schematic. Most likely the issue is related to a similar mechanism we discovered some time ago and published on the E2E Community:

    e2e.ti.com/.../3153.watchdog-timer

    Somewhat recently we discovered a similar mechanism with the CRC mode where a pattern essentially of 0x57xxxx with the 3rd LSB high can enable the CRC without a rising edge on the LATCH pin. It took a bit longer to uncover this mechanism as unlike the WDT topic this does not trigger an alarm response, instead it changes the behavior of SDO to send data out in a 32-bit frame basis instead of 24-bits, so essentially all of the devices down the chain are seeing data which is shifted by a byte.

    Probably the simplest way to avoid the issue is to gate SCLKs to the DACs when other devices on the bus are being communicated with. Otherwise, depending on the details of the other SPI device interface on the bus implementing the CRC mode could be an option as long as it could be implemented within the bounds described here:

    e2e.ti.com/.../3251.crc-frame-error-checking

    I have updated the datasheet, it is going through reviews etc. to update to the website so soon this information should be readily available, though there could be some delays due to the Christmas Holiday in the US.
  • 0 in reply to Kevin Duke
    Prodigy 40 points

    Hello,

    is it possible to use the watchdog timer to avoid this problem.

    If the watchdog active  and the communication is lost, the watchdog should timed out and make a reset of the device.

    In my program code the config register are updated every 100ms to activate the daisy chain mode if the DAC lose the configuration.


    Best regards,

      Michael

  • 0 in reply to Michael Fischer41
    TI__Mastermind 46290 points
    Michael,

    That is a good concept to use the watchdog to detect when the mechanism has occurred and then attempt to disable the CRC in the first device, the only problem is that when the CRC mode is enabled in this way it is not visible in the register map and therefore toggling the enable bit in the register map will not affect whether the feature is enabled or not. So this work around would not be an option.