AnsweredAssumed Answered

AD5270 SDO readback line skew/timing issues

Question asked by dink on Oct 8, 2014
Latest reply on Oct 13, 2014 by dink



We are having some very unexpected performance from our AD5270 integration effort. Specifically, the read back line (SDO) going to the controller is not presenting the data correctly. We have written multiple commands, confirmed the SYNC_n, SCLK, and DIN all meet timing specified on the data sheet (including the 500ns minimum SYNC_n wait time between frames), confirmed that the resistive wiper moves through all 1024 locations (measured with multimeter), the write enable commands are functioning, and the device responds in a somewhat repeatable way. What we can not do is read from the device. SDO has a 2.2K pullup to 3.3VDC (the same bias as the chip). We have clocked the device at 10mhz, 25mhz, and the fmax 50mhz all with identical results. SPI is configured as mode 1 per the data sheet (CPOL =  0, CPHA = 1), and you can confirm that behavior in the provided image.


The attached image shows all four SPI lines between the digipot and the controller measuring directly from the PCB traces near the digipot. Yellow is SYNC_n (or chip select), green is SCLK, red is DIN from the controller, and blue is the SDO line. The table underneath shows four commands written to the device in the MOSI column, and the return as the scope decoded it from digipot in the MISO column. The timing frame shown is the command 0x1800 written to the device, and a return of 0x0C01 from the last frame. When we write 1C03 to the device we expect 1C03 on the return in the next frame, however. From the scope data, the pulses appear too narrow, and arrive too slowly for the controller to read. When we wrote 0x500 to the device, the return data was two bits that were physically so narrow they fully fit inside the SCLK pulse edges, and they were delayed from the expected location.


This behavior has been confirmed on four identical boards. Does anyone have any suggestions as to what may be causing this issue? This is not a problem I've personally encountered until today, with any SPI device.


Thanks for any help you can provide.