Post Go back to editing

AD5696R, AD5695R, AD5694R, how to issue a software reset?

Category: Hardware
Product Number: AD5696R, AD5695R, AD5694R

The current version Rev D. states the following about software reset:

The referenced Table 7 does not add further information.

So: What is the command format to generate a software reset?

There is lacking a table similar to table 15 for instance



what is missing.
[edited by: larsen at 1:12 AM (GMT -4) on 13 Mar 2023]
Parents
  • Hi  ,

    To issue a software reset command, you need to send Command 0110 as found on Table 7. The software reset command does not require any specific values for the DAC address or the DAC data bytes, as they are don't-care values.

    When the software reset command is executed, the DAC channels will be restored to their initial states, which is either zero scale or midscale, depending on the state of the RSTSEL pin.

    For more information on this topic, you may find this post helpful:

    AD5696R Software reset (power-on reset) - Q&A - Precision DACs - EngineerZone (analog.com)

    Best Regards,

    Den

  • Thanks for the answer. May I suggest this information is added to the datasheet?

    In a form similar to table 15 would be great - i.e. all commands should have a register definition irrespective how simple they are. Uniformity of design makes the document easier to navigate.

    Allow me to further illustrate my point with the nLDAC mask register. The datasheet states on page 24

    LDAC MASK REGISTER
    Command 0101 is reserved for this software LDAC function.
    Address bits are ignored. Writing to the DAC, using Command 
    0101, loads the 4-bit LDAC register (DB3 to DB0). The default 
    for each channel is 0; that is, the LDAC pin works normally. 
    Setting the bits to 1 forces this DAC channel to ignore transitions 
    on the LDAC pin, regardless of the state of the hardware LDAC
    pin. This flexibility is useful in applications where the user 
    wishes to select which channels respond to the LDAC pin.

    At first reading this appears clear until you realize that it does not specify the order of the dac's in the register.

    You are left to guess that it is probably the same as the address mask, but you cannot be certain so you must remember to have this as a test case. Then go figure elsewhere in the datasheet - what _is_ the address order actually.

    I'm sure my point is clear by now: A bit pattern table for each register with the relevant explanation next to it.

    Thanks for considering.

Reply
  • Thanks for the answer. May I suggest this information is added to the datasheet?

    In a form similar to table 15 would be great - i.e. all commands should have a register definition irrespective how simple they are. Uniformity of design makes the document easier to navigate.

    Allow me to further illustrate my point with the nLDAC mask register. The datasheet states on page 24

    LDAC MASK REGISTER
    Command 0101 is reserved for this software LDAC function.
    Address bits are ignored. Writing to the DAC, using Command 
    0101, loads the 4-bit LDAC register (DB3 to DB0). The default 
    for each channel is 0; that is, the LDAC pin works normally. 
    Setting the bits to 1 forces this DAC channel to ignore transitions 
    on the LDAC pin, regardless of the state of the hardware LDAC
    pin. This flexibility is useful in applications where the user 
    wishes to select which channels respond to the LDAC pin.

    At first reading this appears clear until you realize that it does not specify the order of the dac's in the register.

    You are left to guess that it is probably the same as the address mask, but you cannot be certain so you must remember to have this as a test case. Then go figure elsewhere in the datasheet - what _is_ the address order actually.

    I'm sure my point is clear by now: A bit pattern table for each register with the relevant explanation next to it.

    Thanks for considering.

Children
  • I can now say with 100% certainty:

    When issuing a software reset command to AD5694R

    1. The address byte is ACK'd (obviously)
    2. The command byte is ACK'd (obviously)
    3. The first data byte (content irrelevant) is ACK'd
    4. The second databyte (content irrelevant) is NACK'd

    What I don't know is if it matters for the reset to be effective if it is sent any data bytes at all. Probably not but I can only guess and test!

    For sure - I don't want any deliberate NACK's to clutter the runtime with exceptions.

    Edit: Tests shows, that

    1. you have to write both two data bytes as indicated above (3),(4) in order for the software reset to be activated!.
    2. you have to deal with the error which is likely to be thrown by the software stack in such case of transfer NACK.

    Another note for the datasheet ;-)

  • Hi larsen,

    Thank you for your feedback and for being active and interested in our products. We are always on the path of improving our product collaterals and resources, and comments like yours really helps.

    Best Regards,

    Den