This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

ADS8528 tDCVB max

Other Parts Discussed in Thread: ADS8528

The ADS8528 datasheet says the max tDCVB is 25 ns (page 9, 10). But it in our scope is longer than 400 ns! Please refer to picture, the trace 1 is CONVST, trace 2 is BUSY. It shows the rDCVB is 460 ns.

Is it an error of datasheet, or we misunderstand it?

Chip : ADS8258SPM

Datasheet version : SBAS543A –AUGUST 2011–REVISED OCTOBER 2011

  • Hi Reed,

    Thank you for your query on the ADS8528!  Great question!  You did not misunderstand the data sheet with respect to the timing diagram on page 9.  The BUSY is expected to go high within 25ns of the rising edge of CONVST when the device is fully powered up and active. 

    Can I ask you about the status of pin 36 - the auto sleep input?  On page 37, the text at the top of the page describes how the BUSY is delayed by 6-7tCCLK when ASLEEP is high.  With the 15MHz CCLK, that would be about 460ns.  Do you have the ASLEEP pin asserted? 

  • Yes, we wrongly pull the ASLEEP up to VDD! Thank you!

    Now we have a new situation... we configure the chip to work 2VREF and range +/- 5V, use an FPGA to gather the ADC data via SPI (enable all channels). When test, we set the input voltage to +2.5V, and expect to get the ADC data around the 03FFh or 0400h. But often we got 1/2 of the correct value, it seems the whole 32-bit data to shift 1 bit right, and there are strange pulses appear and occupy the high bits of the first 16-bit section (last picture). It is shame, we have no idea about what or why does it... Could you help us?

    First 16-bit value 3FBh, it is ok.

    3FFh, it is correct.

    403h, it is ok too.

    200h. wrong, all bits are shifted 1 bit right, and there are strange 11 on the high bits.

  • Hi Reed,

    In your scope captures, it looks like you only have 31 clocks, can you verify that?  From the 3rd to 4th picture, it almost loooks like the LSB got clocked around.  Is that output data going active with your CS/FS input?

  • Hi Tom,

    Yes, the datasheet page 9 shows there are 32 negative pulses, but we think the MSB is driving by FS not the sclk pulse, and the LSB is read on the period after 31st sclk pulse, so the 32nd sclk pulse should be redundant, so we do not pull the sclk down again. Does it affect?

    Reed

  • Hi Reed,

    For the ADS8528, the expectation is that there will be 32 clocks, with the first four output bits being 'zero' followed by the 12-bit conversion result of CHx0.  From there, the device will output another for zeros followed by the conversion results of CHx1.  The leading MSB should always be zero and I suspect what you see is a remnant of the LSB getting shifted out on the first SCLK with a 31 clock cycle transfer.  Add the 32nd SCLK and see if that clears up the problem.

  • We found a tag switch used to trigger CONVST  produces massive bounce, makes FPGA state machine unstable. and the unstable state machine seems to cause the strange SDO signal of ADS8528. We modified state machine to use enum state instead one-hot encoding and sync input signal to system clock into a register. The state machine is stable now, the ADS8528 SDO is stable too. Although we still don't know how the unstable state machine affects the ADS8528 SDO.

    We tried to add a state for SPI-clear that send out the 32nd SCLK. It does not affect the SDO timing at our case. We can cancel the 32nd SCLK safely.

    But we run into another strange situation. We have  manual and ModelSim simulation of the SPI data collection. Both are successful. The ModelSim waves and timing are exactly identical to we observe signals (CNVST, BUSY, FS, SCLK, SDO_*) in scope, and the output data from FPGA in simulation all are correct. But it doesn't on real FPGA (Altera EP1C6T144). We test the FPGA output data pins, confirm all data are just leak a shift of bit, so all data are looked like to divide by 2... We checked the VHDL code both state machine and test-banch many times, does not figure out what will make simulation different to real.. I know it does not look like a problem of ADS8528 but FPGA, However I will appreciate if you can share your opinion to us!

    Thank you!