Post Go back to editing

vInconsistent & Random DATA readout from AD5780 simplest connection

Category: Software
Product Number: AD5780
Software Version: Non-OS Drivers

Hi all,

I am planning to use the AD5780 Demo board for a project. I used Ardunio for simplify the setup. However, despite the correct wiring and connections, it appears that the board does not give a valid read out. Specifically, I connected the AD5780 via SPI interface with Arduino, my code simply do two things, reset and read a "control register". If I understand it correctly, after each reset, the control register should return the same data (the initial default setting after hardware reset). However, what I see is that every cycle, it returns some random number that I cannot find the pattern.

I tracked the connection and power supply, they work as expected, so I am quite sure that they are not hardware failure. The code itself, and a couple of logic analyzer capture are attached for analytics.

Thanks in advance!

#include <SPI.h>
SPISettings settings(1000000, MSBFIRST, SPI_MODE1);

void setup() {
    pinMode(2, OUTPUT); //Used as Chip-Select, CS PIN
    digitalWrite(2, HIGH);

    SPI.begin();
    SPI.beginTransaction(settings);

    //reset seq
    delayMicroseconds(50);

    //Assert RST
    digitalWrite(2, LOW);
    SPI.transfer(0x40);
    SPI.transfer(0x00);
    SPI.transfer(0x04);
    digitalWrite(2, HIGH);

    delayMicroseconds(50);
    //De-assert RST
    digitalWrite(2, LOW);
    SPI.transfer(0x40);
    SPI.transfer(0x00);
    SPI.transfer(0x00);
    digitalWrite(2, HIGH);

    //Attempt read
    delayMicroseconds(50);
    //Read Control REG
    digitalWrite(2, LOW);
    SPI.transfer(0xA0);
    SPI.transfer(0x00);
    SPI.transfer(0x00);
    digitalWrite(2, HIGH);

    delayMicroseconds(50);

    digitalWrite(2, LOW);
    unsigned long a = SPI.transfer(0x00);
    unsigned long b = SPI.transfer(0x00);
    unsigned long c = SPI.transfer(0x00); 
    digitalWrite(2, HIGH);


    SPI.endTransaction();
    SPI.end();
}

void loop() {
  // put your main code here, to run repeatedly:
}

The code is attached above, it is the simplest version (purely for debug purposes).

First execution, you can see that the first two communications are attempting to reset the AD5780, second attempt is to read out the register.

Second image, despite transferring exact same information, the output is different.

The config of the logic analyzer is as follows:

  • note that these two images are essentially the same code, I only altered the delayMicroseconds() here to see the difference.

  • Hi  ,

     will be looking at this query and get back to you.

    Br,

    Den 

  • Here is another issue when trying to read "control" register right after power on reset, nothing is done before / after these two commands. But still we can see here that nothing is sent back. I checked the hardware connections, and I am certain that the hardware side is flawless.

    Am I missing something here on the software side? Is the reading logic looks correct? (The clock frequency here is around 100k, pretty slow and should within the tolerance.)

  • I change the clock to 200K and get some values, though still not expected result.

  • Hi  

    Thanks for your patience. I have missed to respond to this query. Are you still having the same issues? 

    Timing-wise and code wise, I think there are no issues. As you mentioned, it is a straightforward command of resetting the device and reading back from the control register. 

    Can you try to increase the delay from writing the reset command, to reading back from the control register to around 1ms just to be sure. It was't mentioned in the datasheet, but a lot of times we need to give some time for the device to do its POR sequence internally before communicating. By default we should be reading back 0xDDDD2E (Ds are dont care and I'm just looking at the last byte)

    Also can you do me a favor and look at your power supply sequence. From p23 of the datasheet, we need to make sure that VDD needs to power up before VCC. Else the device does not start up as expected. 

    Best regards,

    Ian

  • Yes, unfortunately the issue still persists. Note that the power on sequence is indeed required as VDD is powered on first. To clarify, I am testing based on the AD5780 EVAL board, EVAL-AD5780.

    My power on sequence is VDD (+15V) at t0, VCC (+5V) at t0+1 sec, VSS (-15V) at t0 + 2 sec. The rule of "power VDD before VCC" is satisfied.

    After power-on sequence, the reset-read config sequence is performed. Nothing else is performed before & after these operations (for debug purpose).

    As what I have did previously, the first package is 0x400004, the reset sequence after power on (for testing), delayed 1ms, the second package is 0xA00000 (attempting to read control register). The third package is what we expect to read-back, but unfortunately nothing is read correctly. 

    (Close up of the first packet)

    (Close up of the second packet)

  • Hi, sorry to get back late, the issue still persist despite power on timing is correct. I might reply to the post in a wrong sequence, but you can find it.

    Also, I noticed oscillations along the communication line, for example like this.

    The problem persists, for example the DAC return incorrect values or meaningless information.

    For example, here, this info represents invalid info sent back from DAC.

  • Hi, sorry to get back late, the issue still persist despite power on timing is correct. I might reply to the post in a wrong sequence, but you can find it.

    Also, I noticed oscillations along the communication line, for example like this.

    The problem persists, for example the DAC return incorrect values or meaningless information.

    For example, here, this info represents invalid info sent back from DAC.

  • Hi, 
    Can you check if your controller's logic voltage is the same as VCC at 5V? I'm confused at the scope plot showing 350mV amplitude on the signal.
    Please also check you jumper settings and compare with the userguide. UG-256 (Rev. A)

    Have you tried writing to the DAC, enabling outputs, see if the device outputs correctly?