Post Go back to editing

SDO is abnormal when AD5689 enable daisy chain.

Category: Software
Product Number: AD5689

Hi,

I'm using AD5689 for data acquisition, the MCU is KEA128, and the IDE is S32DS of NXP.

I connected 4 AD5689 together and enabled daisy chain, reference data sheet P19.

But I didn't connect LDAC pin. I saw that this pin can be low, reference data sheet P7.

I got correct data on A_OUT and B_OUT of the first and the second AD5689, but I didn't get correct data on the third and the fourth AD5689.

I found that the SDO data is wrong on the second AD5689, and the waveform as below.

Sometimes I can get correct SDO data on the second AD5689 in debug mode in S32DS IDE, but I never get correct SDO data in release mode.

Following is the setting of daisy chain enable.

AD5689_SetRegisterValue(CMD_DCEN_REG, DAC_ALL, 1); //CMD_DCEN_REG =8, DAC_ALL=9


void AD5689_SetRegisterValue(uint8_t command, uint16_t channel, uint16_t data)
{

uint8_t reg[12]={0};
uint8_t rx[12] = {0};

reg[0]=(command<<4)|channel; //cmd+channel
reg[1]=(data>>8)&0xFF; //high 8 bits
reg[2]=data&0xFF; //low 8 bits


reg[9]=reg[3]=reg[6]=reg[0];
reg[10]=reg[4]=reg[7]=reg[1];
reg[11]=reg[5]=reg[8]=reg[2];

AD5689_SYNC_D(0);
SPI_TransferWait(SPI1, rx, reg, 12);
AD5689_SYNC_D(1);
}

And the send data function is like below.

void AD5689_SendData(void)

{
uint8_t spiAry1[12];
uint8_t spiAry2[12];
uint16_t testcnt = 0;
uint8_t rx[12];


//DAC1---CHA---FX
testcnt = 50000;
spiAry1[9] = 0x31; //write and update CHA
spiAry1[10] = (testcnt>>8)&0xFF; //high 8 bits of FX
spiAry1[11] = testcnt&0xFF; //low 8 bits of FX

//DAC1---CHB---FY
testcnt = 50000;
spiAry2[9] = 0x38; //write and update CHB
spiAry2[10] = (testcnt>>8)&0xFF; //high 8 bits of FY
spiAry2[11] = testcnt&0xFF; //low 8 bits of FY

......// set DAC2~DAC4

//transfer data by SPI

AD5689_SYNC_D(0);
SPI_TransferWait(SPI1, rx, spiAry1, 12);
AD5689_SYNC_D(1);

AD5689_SYNC_D(0);
SPI_TransferWait(SPI1, rx, spiAry2, 12);
AD5689_SYNC_D(1);

}

Top Replies

    •  Analog Employees 
    in reply to Lingjun +1 verified

    Hi  ,

    Based on the additional information provided, it seems the issue could be with the timing of the SPI communication not meeting the SDO data valid timing requirement specified in the AD5689 datasheet…

Parents
  • When there is no data transfer, the SDO of the first AD5689 is always high, but the SDO of the second AD5689 sometimes is high and sometimes is low.

    I'm not sure whether it is correct or not.

  • Hi  ,

    1. It is not advisable to leave LDAC floating, as this may result in unpredictable behavior. You may tie it to ground if you want it to continuously update.
    2. The datasheet suggests that the SDO pin is not open drain, this means that it does not need a pull-up resistor.
    3. Daisy-chain operation is disabled by default. You need to manually enable it. However, it is not enough to enable it once, as this will only enable the daisy chain for the first DAC. To enable all 4 DACs, you may follow this sequence:
    DCEN mode
    DCEN mode -> NOP
    DCEN mode -> NOP -> NOP
    DCEN mode -> NOP -> NOP -> NOP
    This is to clock out the enabling bits to the other DACs. For more details, you can refer to the information and block diagram in the datasheet under "Daisy-Chain Operation".

    Best Regards,

    Den

  • Hi Den,

    Thank you very much for your reply. I have enabled all chips daisy chain mode.

    And I have some other questions.

    The first and second AD5689's OUT_A and OUT_B is correct, but the third AD589's OUT_A and OUT_B is wrong.

    Because the second AD5689's SDO is always low, there is no data on this pin. 

    This case always appears at release mode, and sometimes appears at debug mode.

    That means sometimes there is correct result on the third AD5689's OUT_A and OUT_B.

    It seems that the SDO of the third AD5689 is not stable.

    Is it the hardware problem?

    Could you please give me some suggestion to debug this problem.

    Looking forward to your reply, thank you very much!

    Best regards,

    Lingjun

  • Hi  ,

    1. Double check the daisy chain connections between the 2nd and 3rd AD5689. Make sure SDO of 2nd AD5689 is properly connected to SDI of 3rd AD5689. Also check that the SYNC lines are connected properly

    2. Try swapping the 2nd and 3rd AD5689 and see if the issue moves to the new 3rd AD5689. If it does, this might be a confirmation that there is an issue with that particular chip.

    3. Double check your SPI connections and configuration. Although the issue seems to be in daisy chain, it won't hurt to recheck SPI as well.

    Best Regards,

    Den

  • Hi Den,

    Thank you very much for your reply.

    I can't swap the 2nd and 3rd AD5689 because they are designed on one PBC board.

    In order to verify the 3rd one, I connect another AD5689 after the 3rd AD5689, and started at the 2nd AD5689. The SDO of the 2nd AD5689 is correct and the OUT_A and OUT_B of the 3rd AD5689 is correct. But the SDO of the 3rd AD5689 is wrong.

    I check the datasheet again, I found there is a timer I can't conform.

    T9 defined the timer that SDO Data Valid from SCLK Rising Edge, the max value is 30ns.

    But in my project, the SPI of NXP KEA128 transfer one byte a time, so the time from SCLK Rising Edge to SDO Data Valid is more than 30ns, waveform as below.

    Do you think it is the reason that there in not data on the SDO of the 2nd AD5689? 

    Looking forward to your reply, thank you very much!

    Best regards,

    Lingjun

  • Hi Den,

    Is there any driver code for this chip?

    I want to check whether my driver code is correct.

    Best regards,

    Lingjun

  • Hi  ,

    Based on the additional information provided, it seems the issue could be with the timing of the SPI communication not meeting the SDO data valid timing requirement specified in the AD5689 datasheet. The SDO Data Valid time from SCLK Rising Edge is specified in the datasheet as 45ns (1.62 V ≤ VLOGIC < 2.7 V) or 30ns (2.7 V ≤ VLOGIC ≤ 5.5 V ). This means that the data on the SDO pin will be valid 30ns after the SCLK rising edge. If your SPI transfer takes longer than 30ns, then it is possible that the data on the SDO pin will not be valid by the time the next SCLK rising edge occurs. This could lead to the problem you are seeing.

    A few suggestions:

    1. Try increasing the SPI frequency if possible, so the time between SCLK rising edges is reduced. This may help meet the 30ns timing requirement.

    2. Review the SPI code and see if any optimizations can be made to reduce the time between SCLK edges. For example, minimizing any delays between sending bytes.

    3. I haven't found any official driver code for AD5689 but I found some resources online for AD5686 NO-OS Drivers, which is within the same nanoDAC+ family that you may check.

    NO-OS Driver Wiki

    Understanding and Using the No-OS and Platform Drivers

    Best Regards,

    Den

Reply
  • Hi  ,

    Based on the additional information provided, it seems the issue could be with the timing of the SPI communication not meeting the SDO data valid timing requirement specified in the AD5689 datasheet. The SDO Data Valid time from SCLK Rising Edge is specified in the datasheet as 45ns (1.62 V ≤ VLOGIC < 2.7 V) or 30ns (2.7 V ≤ VLOGIC ≤ 5.5 V ). This means that the data on the SDO pin will be valid 30ns after the SCLK rising edge. If your SPI transfer takes longer than 30ns, then it is possible that the data on the SDO pin will not be valid by the time the next SCLK rising edge occurs. This could lead to the problem you are seeing.

    A few suggestions:

    1. Try increasing the SPI frequency if possible, so the time between SCLK rising edges is reduced. This may help meet the 30ns timing requirement.

    2. Review the SPI code and see if any optimizations can be made to reduce the time between SCLK edges. For example, minimizing any delays between sending bytes.

    3. I haven't found any official driver code for AD5689 but I found some resources online for AD5686 NO-OS Drivers, which is within the same nanoDAC+ family that you may check.

    NO-OS Driver Wiki

    Understanding and Using the No-OS and Platform Drivers

    Best Regards,

    Den

Children
  • Hi Den,

    Thank you very much for your suggestion.

    I have solved the problem.

    The root cause is that sometimes the daisy-chain enable is not successful, waveform as below.

    I don't understand why the 2nd AD5689 get data from 1st AD5689 when daisy-chain enable failed.

    I enable daisy chain two times after initializing this chip, and all channels can work normal.

    I think if there is a mechanism to check whether daisy-chain enable successful will avoid this problem.

    Thank you for all your support~~~

    Best regards,

    Lingjun