I am using a combination of 3 AD5380, all in stand-alone mode (control via SPI), to get desired voltage levels on any of the channels of this DACs. The SPI has different slave-select lines to select one of the 3 DACs for communication.
The SPI communication works as expected, but not for the first SPI transfer.
The first SPI transfer actually set the same channel on all the 3 DACs. There are actually 2 issues here
(a) in SPI: when I initialize my SPI-SW module for the first time, due to a HW feature!, all the salve select lines are pull low for a very short duration of 5us. This cannot be avoided.
(b) in AD5380, now since all the SYNC-N lines were pulled low for 5us, somehow all 3 DACs "become ready" to accept the command on DIN that would follow (note: the SCLK are also shared). Although the command would be targeted at only one of the DACs (whose slave select would be pulled low and the corresponding DACs SYNC-N pulled low), due to this strange issue in AD5380, the remaining 2 DACs also accept this command. Hence in all 3 DACs, that one channel (specified in the 24-bit SPI command) are set to a same voltage. This is not desired.
Can you please confirm if my observation is correct. From the data sheet, the value t6 says should be 33 ns (in Standalone), so this actually confirms my observation is correct; but I am not sure. If my observation is incorrect then I have to further look into my HW design if something nasty is happening, because other than this single issue, everything else seems to work fine.
Your help will be much appreciated. Thank you.
Can you send a scope shot of the SCLK and the SYNC lines for the 3 AD5380s?
I'm suspecting that the SYNC lines for the other 2 DACs were not pulled high long enough that is why they responded to the command which was supposedly only for the first DAC.
These SYNC high time should be at least 10ns. Kindly see Figure 3 on the data sheet for reference.
Thank you for the quick response.
Attached is a plot, hope its readable.
At the trigger point, where you see 2 spikes, that's where the SW SPI module is initialized.
As you can see there is enough time provided between this initialization and the SPI communication.
P.S: I have not captured the 3rd DAC SYNC, instead captured the DAC1 and DAC2 SYNC lines and the corresponding voltage out lines.
Additionally, find another pic, showing the connections. I think you have understood this, but none-the-less; clarifying one point that I am not using the SDO line from the DACs
(note: I know that we could directly use the 3.3V, however as of now, I want to make it work with 5V)
What could be the reason?
It seems that the delay is sufficient before the first write based on your scope shot.
I have to confirm with the designer if this is really the case for operating multiple AD5380s in parallel.
In the mean time, can you try performing a hardware reset on the three parts after the initialization of the SPI-SW module and see if this resolves the issue?
Thank you for the reply. Very much appreciated.
Yes, a hardware reset (pull RESET_N line LOW), clears the voltage; and also checked that the same behavior is obtained by sending "Soft CLR" command via SPI (since the default on power-up is all zeros for CLR register).
But I really would want to know your findings with the design team (that the SYNC need not be LOW during communication and data can be sent much later - even if the gap is in seconds - after asserting the SYNC for even short pulses like 5us). If you confirm, then I can document it somewhere along with above workaround (in our project), so that, it helps the team in better maintenance of the product.
I missed this earlier on, but the serial interface was briefly discussed on the data sheet on page 27, Standalone Mode section.
"The first falling edge of SYNC starts the write cycle and resets a counter that counts the number of serial clocks to ensure that the correct number of bits are shifted into the serial shift register. Any further edges on SYNC, except for a falling edge, are ignored until 24 bits are clocked into the register. Once 24 bits have been shifted in, the SCLK is ignored."
With this, what you were encountering is expected. I'm glad that the HW/SW was able to address the issue.
Let me know if you have any further questions.
Thanks and best regards,