AD5423 always in fault

Hi Dave,

Someone is currently looking into this and will respond the soonest possible time.

Cheers,

Ivan

Hi,

Is there any update on this please?  We are waiting to validate a prototype board but cannot since we cannot communicate with the IC?

Thank you.

Hi Dave,

What exactly is the fault? Can you communicate at all with the part?Are you using the eval board and ACE software?

Valerie

Hi Dave,

The AD5758 has the same digital interface as the AD5423 so perhaps the AD5758 drivers may be of use here?

https://wiki.analog.com/resources/tools-software/linux-drivers/iio-dac/ad5758

Valerie

Hi Valerie

It's been a while since you responded to this and I've come back to this, assuming that we could make it work when we needed it, but for some reason we're not able to.

Whenever we communicate with the AD5423 the FAULT pin instantly goes low.

I've used the code at both your link above, and here to confirm our packets are correct.

For instance, the primary packet we've been attempting to transmit without a FAULT is the CRC disable using the 'ad5758_crc_disable' function in the linux driver as the reference.

This equates to 4 bytes: 0x90 0x00 0x5C 0x3A.

Our checksum code we had worked out was correctly generating this checksum for the disable message, so that was good to confirm.

We have verified on a 4 channel scope that the NSS/CLK/MOSI are all sending these 4 bytes, as 32 bits, MSB.  The no-OS driver shows SPI mode 1 at 1MHz so we set that (although I've tried SPI mode 0/1/2/3).

Our AD0/AD1 are both tied low, but I tried sending the message with an AD1 high and slip low in case our hardware is not seeing the low.

Voltages are with spec.  We've probed each external pin and confirmed voltages and things like internal LDO are on at spec.  This is on 2 different boards.

As some graphics in the manual say 'timing with LDAC low' we've tried LDAC high and low. 

It's a mystery...

This person reported a similar situation: https://ez.analog.com/data_converters/precision_dacs/f/q-a/110824/ad5758-miso-isnot-responding

I reached out and they said it was a board fault with no further detail, but we've been pretty thorough at checking our design matches the manual and is a variant of the eval board, but... that person was having the same symptoms so there must be a path to 'hardware issue' being able to cause a FAULT on first comms.

Do you have anything you can suggest we can try next?

Many thanks, Dave

Here are some screenshots of our SPI capture:

We are on a STM32... This is with these options:

  hspi1.Init.CLKPolarity = SPI_POLARITY_LOW;

  hspi1.Init.CLKPhase = SPI_PHASE_2EDGE;

We have this set to best match the timing sheet:

CLK/NSS/MOSI/MISO with scope decode

CLK/NSS/MOSI/FAULT

This is a zoom of the timing:

It appears to match the timing diagram.

The STM32 does appear to clock data in 16bit blocks under interrupt but since NSS is low throughout that shouldn't be an issue.

Hi Dave,

What is the first write you are trying to send to the AD5423? There is a calibration memory refresh that must be issued first. This must be performed before any other or write or you will get a INVALID_SPI_ACCESS_ERR flag in the Digital Diagnostic Results register. Is this the error flag you are getting?. 

Valerie

Hi Valerie

Both the reference source code drivers do not do this.  They either call Reset or DisableCRC and the Reset before calling the calibration memory refresh.

And yes, we did try calling this first (our original code did, per the manual), but it too goes into FAULT.

Regards, Dave

Update... we just retested per request and it appears to not go into fault if this is the first command.

Will test further.

Hi Dave,

I am not sure what write you are trying to do? Looks like write to register 0x9 and then register 0x5? Can you send me the exact writes you are sending to the part? The first 2 will do? Also are you able to read anything from the part? This process uses a two stage readback which means you write to address 0x13 with the address of the register you want to read as the data, then you must send a NOP which is write all zeros to register address 0x00. 

Valerie