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.

ADS7953 - Cannot Change Channels / Garbage Conversion Data

Other Parts Discussed in Thread: ADS7953

I’ve got an ADS7953 that I’ve created a breakout board for and am currently in the process of testing it. Here’s the schematic for the breakout board:

Here’s the board layout:

I’m interfacing with the ADC via an FPGA (Spartan 6 LX45 -2) that’s part of a larger dev board, the Opal Kelly XEM6310. I’ve confirmed that I’m successfully getting the SCLK, SDI, and CS# signals out of the chip. Here’s a photo of SCLK oscillating shown on an oscilloscope (signal 13):

Here’s CS# toggling for each frame (signal 12):

I checked these signals with the scope just to determine that the signals were actually making it out of the FPGA to the I/O pins.

I’ve attached the VHDL I’ve written for the FPGA to this post. Essentially, I wait for a start signal from the PC and start communication with the ADC after that. Here are the relevant signals for the ADC shown in FPGA simulation:

As you can see, I update SDI on falling edges of SCLK since it’s latched by the ADC on rising edges, and I capture SDO on rising edges since it’s output by the ADC on falling edges. I’m using manual mode and selecting the next channel in each frame. Right now, I’m just sticking to 1 channel (channel 1 in this case), so the SDI pattern should the the same for every frame. The data that comes in from the ADC is captured in a 16-bit register and is written into a FIFO. Once that FIFO fills, a signal is sent to the PC and the data is piped out of the FPGA and into MATLAB for processing. I ignore SDO on the first frame (fifo_wr_en, the write enable for my FIFO doesn't go high until after the first frame, which is shown above). This is because the first frame on power up doesn't contain valid SDO data The clock I'm using is generated by dividing an external 100.8 MHz clock provided by the Opal Kelly development board. The resulting clock is 12.6 MHz. As a side note, ignore the FIFO signals at the bottom of the simulation window; I forced the full signal high to test that my design behaved as expected when the FIFO filled.

For my test setup, I’m feeding +VBD 3.3 V from a DC power supply and +VA 3.3 V from another DC power supply. I’m not using a voltage reference; I’ve got a 2.5 V DC power supply hooked up to REFP (I realize this isn’t ideal). I short MXO and AINP together with a wire. SCLK, SDI, SDO, and CS# all connect to I/O pins on the FPGA.

I first tested the ADC by feeding in a 1 VPP 100 kHz sine wave from a function generator into channel 0. In MATALB, I piped out the collected data and took the lower 12 bits of each 16-bit word to get the conversion data. When I plot that, it looks like noise. I checked the upper 4 bits, and they were all 0, as expected since I’m reading from channel 0. Next, I tried the same thing, but this time using channel 1. Again, the conversion data looked like garbage, but the upper 4 bits of the 16-bit words were all still 0, not 0001 as should be expected for channel 1.

This makes me think that I have an issue with the serial interface, since I can’t seem to select channels properly. If I can at least get that working, I’ll have confidence that the digital side of things is working, and I can then focus on cleaning up the analog side if need be.

Any help is greatly appreciated!

  • Hi Hayden,

    Thanks for the detailed information regarding your query.

    Looking at the FPGA simulation, the timing pattern seems to be fine. Could you please share oscilloscope capture showing two frames. Please include CS, SCLK, SDI and SDO in the oscilloscope plot and capture them simultaneously. It will be great if you could probe these signals on your breakout board.

    This will help us rule out any data transfer issues between device SDO and FPGA' FIFO. As you are operating in manual mode - channel 1 , the channel ID must reflect that. This part can be confirmed by looking at the oscilloscope waveform.

    Regards,
    Rahul
  • Hi Rahul,

    Thanks for your reply. I realized that I forgot to include the VHDL code for my initial post; if that would be helpful, I can grab it from my work computer soon.

    Here are the relevant scope captures. Channel 8 is SCLK, 9 is CS#, 10 is SDI, and 11 is SDO. Channel 1 is probing CS# and triggering on it. This is a shot showing the first two frames:

    One potential problem I immediately see is that my input signals appear to be glitching a bit. This is more evident when I zoom in. Here's the first frame, zoomed in:

    And here's the second frame zoomed in:

    Let me know if there's anything else I can provide to help, and thanks for your assistance!

  • Hi Hayden,

    The intermittent glitches on digital lines will violate timing spec and can cause misbehaviour in the ADC.
    It is necessary to clean up the digital inputs to the ADC before trying to interpret the ADC output.

    Regards,
    Rahul
  • Hey Rahul,

    I slowed the SCLK rate way down to about 201.6 kHz to see if that would help with the glitching we saw earlier. I'm supplying a 10 kHz, 2 Vpp sine wave to channel 1 of the ADC. This fix appears to work, based on the scope output I'm getting now. However, the channel selection still isn't working properly, and the data coming out still just looks like noise. In these first two photos, you can see the glitching is gone, but the ADC seems to respond with the channel ID 0010 instead of 0001:

    I tried power cycling the FPGA and did another scope collect and got weird results where the channel ID seems to be 0000 from frame to frame. Here's that:

    Aside from the channel IDs changing and being wrong, the data still looks like noise as well.

  • Hi Hayden,

    I am sorry for the delayed response.

    As I can see in your oscilloscope plots, the digital lines still have glitches. It will be very difficult to estimate device behaviour in uncertain digital conditions. You will need to clean-up the digital logic in the FPGA to ensure there are no glitches on the digital lines.

    With the digital signalling fixed, we can have a look at the problem again, if it still stays.

    Regards,
    Rahul