I am using AD9681 in my design. Reading Chip ID register (address 0x0001) returns value 0x8E, but datasheet tells me that it shoul be value 0x8F. What is wrong?
I think the datasheets are OK. The AD9253 has several speed grades available so that number will vary.
Please check on your reading of Bit0, if you are concerned about the register values.
Thank you for using the AD9681.
What register values to you get when you read other registers? For example, what values do you see when you read Register addresses 0x00 through 0x05?
There is a output log from my embedded software :
Responce from ADC ADDR: 0x0 VALUE: 0x18Responce from ADC ADDR: 0x1 VALUE: 0x8EResponce from ADC ADDR: 0x2 VALUE: 0x62Responce from ADC ADDR: 0x3 VALUE: 0x0Responce from ADC ADDR: 0x4 VALUE: 0xEResponce from ADC ADDR: 0x5 VALUE: 0x3E
Here is the chip photo.
Thank you for the information. Your output log shows data where Bit0 is always 0.
The default values I read are as follows:
Register 0x00 = 0x18 (Bit0 = 0)
Register 0x01 = 0x8F (Bit0 = 1)
Register 0x02 = 0x63 (Bit0 = 1)
Register 0x03 = 0x00 (Bit0 = 0)
Register 0x04 = 0x0F (Bit0 = 1)
Register 0x05 = 0x3F (Bit0 = 1)
As can be seen, Bit0 is sometimes 0, sometimes 1 in the default values of the first six SPI registers. Is it possible that your system is misreading Bit0?
There is one more strange thing : Chip ID and Chip Grade for AD9681 and for AD9253 have (in accordance to datasheets) the same values : 0x8F and 0x60. Is it true, or maybe it is a mistake in datasheet?
Thanks for your suggestion, You was right - my software incorrectly reads lates data bit (bit0 in my case).
Let me describe why it happens - maybe it will help somebody to overcome similair problem.
For reading command data bits are shifted out from AD9681 after falling edge of SCLK. It is true for all data bits.
So my software drive SCLK low, wait short delay (for SCLK speed limit), than drive SCLK high, wait short delay one more time and than reads SDIO line. All the data bits are read succesfully, but bit 0 is always read as zero. It happens
because AD9681 puts SDIO line to high-Z state immediately after 24th SCLK rising clock edge (in the middle of data bit 0). As the result SDIO line without any driving source slowly goes to zero state. In my case after approximately 200nS after 24th SCLK rising edge I always got zero from SDIO data line. Look ta the folowing picture :
Here blue channel - SDIO line, red channel - CS1+CS2(tied together).
First marker - 23th SCLK falling edge,
Second marker - 24th SCLK rising edge.
I made a simple workaround for this issue - just read the SDIO line BEFORE driving SCLK high for all data bits,
but not AFTER. It is easy to modify my SPI algorithm because it is software driven. But it seems to me that it will
be a great headache for hardware SPI implementation (FPGA core or ASIC core).The my suggestion is to put SDIO data line to High-Z after 24th SCLK FALLING edge or CS rising edge (who comes first). It is important to fix this issue
in future AD SPI implementations.
Thank you for sharing your findings for the benefit of the EngineerZone community.
As you stated, serial SPI data is transmitted on the falling edge of SCLK. Using the falling edge of SCLK as the active capturing edge, it seems that hardware SPI receivers would not have a problem capturing data before the next rising edge of SCLK.
Thanks again. I hope your project goes well.
Retrieving data ...