Post Go back to editing

AD5410: Software reset in daisychain mode

Hi,

I have two AD5410 in daisychain configuration.

For initialization, I'd like to perform a software reset as described in the datasheet (fig. 40), as I can't tell in which state the devices are (maybe some previous config maybe some unknown powerup).

As far as I understand the daisychain mode, the reset command 0x560001 has to be sent in one 24bit-command to the first device and toggled to the 2nd device by sending NOP 0x000000. With an additional NOP, the 0x560001 should appear at SDO (for a possible next device or a readback for verification of the communication).

However, only the first device seems to get the command:

Other commands seem to get passed correctly from SDI to SDO in the next command.

How can I do the software reset of all devices in the daisy chain?

If the devices are in standalone-mode (which they should be the first time the initialization is done), any command with multiples of 24bit should be ignored, so sending the software reset in daisychain mode should have no effect, but it seems that the reset command itself is not forwarded to the next device (maybe the output shift register is also cleared) - I don't have an idea how to get through this problem

Best regards,

Simon



Add details
[edited by: ENV_SD at 7:32 PM (GMT -4) on 2 Aug 2021]
Parents
  • Hi Simon, 

    Firstly, you must enable daisy chain feature per device. It should be disabled by default. 

    Second, the proper daisy chain transaction is like this. To talk to the 2nd device, 24 clocks + 24 clocks must be sent before latch is asserted high (rising edge). You can see it in figure 4 of the datasheet. 

    For your case, what you can do is this. Note that each <command> is 24clks and a /L means latch is asserted high (rising edge).

    <Software reset command> /L - targetted to the first device. 
    <DCEN command> /L - enable DC for the first device. 
    <Software reset command> <NOP>  /L - Targetted to the 2nd device (total 48 clks, latch is at the end of the 48)
    <DCEN command> <NOP> /L - enable DC for the 2nd device. 
    <Software reset command> <NOP>  <NOP> /L - Targetted to the 3rd device 
    <DCEN command> <NOP> <NOP> /L - enable DC for the 3rd device. if necessary

    Best regards,

    Ian



  • Hi Ian,

    thanks for the answer.

    I modified the procedure a little bit and ended up with the following:

    <DCEN command with output disable> /L - enable DC for the first device

    <NOP> /L - forward the DC enable command to the second device, etc. until it is forwardet to MISO

    ...

    <write DATA register !=0> <write DATA register !=0> /L - write dummy value to be able to verify reset afterwards

    <read DATA register> <read DATA register> /L

    <NOP> <NOP> /L - verify that the register has been correctly written

    <Software reset command> <Software reset command> /L - reset all devices

    wait  a bit (sending additional commands immediately seems to get lost)

    <DCEN command with output disable> /L - enable DC for the first device

    <NOP> /L - forward the DC enable command to the second device, etc. until it is forwardet to MISO

    ...

    <read DATA register> <read DATA register> /L

    <NOP> <NOP> /L - verify that the register has been reset to 0

    This seems to work as expected, after I inserted some wait period after the reset command - when I tried to send the next commands immediately, they seemed to get lost (which led me to the not-so-intuitive method of figuring out if the reset command was performed correctly). From the datasheet alone I didn't realize that the waiting after software reset is also necessary for the SPI bus to be working again.

    Best regards,

    Simon

  • Hi Simon, 

    It's great that you got it working. The delay after software reset is something I personally think we lack from our product datasheet. What we normally suggest is to wait for around 100 to 200us for the internal registers to return to their initial state upon reset. 

    Best regards,

    Ian

Reply Children
No Data