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.

ADS1256: Issue in reading during both continuous cycling and muxed cycling

Part Number: ADS1256

Hi,

I am using 4 x ADS1256 ICs on our board. 1st 3 ICs are configured to read one differential channel and 4th IC one is configured with 4 single-ended channels.

All differential channels are programmed for continuous cycling. Remaining single-ended channels programmed are using MUX cycling.

CLKIN is 7.68 MHz, SCLK is 1.92 MHz, DRATE is set to 3750 for both continuous cycling as well as muxed cycling.

The sequence of program for continuous cycling is:

1) Issue SDATAC command on the falling edge of DRDY.

2) Update STATUS REGISTER (hx00)  on next falling edge of DRDY followed by delay of 5 micro seconds

3) Update ADCON REGISTER (hx00)  followed by delay of 5 micro seconds

4) Update DRATE REGISTER (hxC0) followed by delay of 5 micro seconds

5) Issue SELFCAL command on the next falling edge of DRDY followed by delay of 5 micro seconds

6) Update MUX REGISTER (hx01)  on next falling edge of DRDY 

7) Issue RDATAC command on next falling edge of DRDY followed by delay of 8 micro seconds

8) Read DOUT (of 24 bits) 

9) Continue to Read DOUT (of 24 bits) on falling edge of every DRDY

Observation & Issues on all 3 differential channels

1) The desired DRATE is confirmed to be set on the oscilloscope with high time of 2.5 microseconds and remaining low for remaining period of DRDY period.

2) SCLK is being generated as per program sequence for 24 pulses with period of 0.52 microseconds

3) The DOUT remains high always because of which we are not getting readout properly. Kindly help us to resolve the issue

The sequence of program for MUXED cycling of 4th IC with 4 single-ended channels is:

1) Issue SDATAC command on the falling edge of DRDY.

2) Update STATUS REGISTER (hx00)  on next falling edge of DRDY followed by delay of 5 micro seconds

3) Update ADCON REGISTER (hx00)  followed by delay of 5 micro seconds

4) Update DRATE REGISTER (hxC0) followed by delay of 5 micro seconds

5) Issue SELFCAL command on the next falling edge of DRDY followed by delay of 5 micro seconds

6) Update MUX REGISTER (hx81 for 2nd SE-Ch)  on next falling edge of DRDY followed by delay of 5 micro seconds

7) Issue SYNC, WAKEUP, RDATA commands sequentially followed by delay of 8 micro seconds

8) Read DOUT (of 24 bits) of hx80 1st SE-Ch

9) Update MUX REGISTER (hx82 for 3nd SE-Ch)  on next falling edge of DRDY followed by delay of 5 micro seconds

10) Issue SYNC, WAKEUP, RDATA commands sequentially followed by delay of 8 micro seconds

11) Read DOUT (of 24 bits) of  hx81 2nd SE-Ch

12) Update MUX REGISTER (hx83 for 3nd SE-Ch)  on next falling edge of DRDY followed by delay of 5 micro seconds

13) Issue SYNC, WAKEUP, RDATA commands sequentially followed by delay of 8 micro seconds

14) Read DOUT (of 24 bits) of hx82 3rd SE-Ch

15) Update MUX REGISTER (hx80 for 1st SE-Ch)  on next falling edge of DRDY followed by delay of 5 micro seconds

16) Issue SYNC, WAKEUP, RDATA commands sequentially followed by delay of 8 micro seconds

17) Read DOUT (of 24 bits) of hx83 3rd SE-Ch

Observation & Issues on all 3 differential channels

1) The desired DRATE is confirmed to be set on the oscilloscope with high time of 2.5 microseconds and remaining low for remaining period of DRDY period.

2) SCLK is being generated properly (as per program sequence during both read and write operations) 24 pulses with period of 0.52 microseconds

3) The DIN is found to be as programmed sequence.

4) However DOUT signal will not show up immediately after t6 delay after RDATA command instead shows up only during when DRDY is low i.e. when DIN is active. It looks like continuous mode is still active though first command issues was SDATAC.  Please help us to resolve the issue.

We are struggling with these issues from quite some time. Immediate help will be appreciated.

With kind regards,

Somayya

  • Hi Somayya Ammanagi,

    Can you view your communication sequence with a logic analyzer and send us the images? It is a bit difficult to know what is going on without being able to see the actual communication.

    Please include SCLK, DIN, DOUT, CS, DRDY. Please also make sure that your PWDN and RESET pins are pulled to the appropriate levels

    -Bryan

  • Dear Bryan,

    Thanks for your prompt reply. The ADS1256 program is implemented using FPGA Verilog code on processor Artix-7. My observations were made on oscilloscope, where I could see only two signals at a time. As you suggested, I will confirm the PWDN and RESET levels and provide the observations of SCLK, DIN, DOUT, DRDY on ILA. In our case CS is always kept low and PWDN and RESET are always set high.

    With kind regards,

    Somayya

  • Hi Somayya Ammanagi,

    Let me look into this tomorrow and I will get back to you. Thanks for your patience!

    -Bryan

  • How to ensure SDATAC is effectively executed and MUXed cycling is active?

  • Hi Somayya Ammanagi,

    Do you have CS tied low for all 4x ADCs on the board? If so, they do not share SPI signal e.g. DIN, DOUT, SCLK, etc., correct? In other words, you have 4x separate SPI peripherals to communicate with each device?

    Can you let me know what you are trying to show in the logic analyzer plots? I assume the first image you sent is from the ADC where you are continuously converting a single channel. And the second and third images are from the ADC where you are multiplexing through channels - is that correct? If so, what is the difference between the second and third image? It is hard to tell which commands you are trying to send since I cannot zoom in on the waveforms. Maybe it would help to send a close up image of the communication for one channel (MUX change, sync, wakeup, read) and then a zoomed out version of multiple channel reads

    It is hard to tell, but it looks like there is some activity on DOUT when you are multiplexing through channels. Is this data valid?

    To check what data you are receiving and which channel is being sampled, I would just apply different voltages to all channels. So if you are using 4x channels, I would apply 1V to channel 1, 2V to channel 2, etc., This will help you understand if the mux is cycling properly or just stuck on one channel.

    The only way to check if the SDATAC command is working is to enter the command (using the correct timing, etc.) and then see if you get valid data out of the device after subsequent DRDY pulses without having to send the RDATA command. I would first confirm that you can read data correctly e.g. a 1V input on the channel gives you an ADC output code that is ~1V. This ensures that you know what your data output should be before you confirm the operation of SDATAC.

    -Bryan

  • Dear Bryan,

    Thanks for your response.

    Yes, CS is tied low for all 4xADC ICs, and they do not share SPI signals DRDY, SCLK, DIN, DOUT i.e. each device has a separate SPI communication.

    First 3 ICs are configured for one differential channel (continuous cycling to get higher throughput) on each IC to get simultaneous sampling.

    Fourth IC is configured for 4x Single-Ended channels (muxed cycling for low throughput).

    The second graph corresponds to signals of 4th IC configured with MUXed cycling. Now we are able to get it to working properly as per data sheet and the same is shown in Graph 3 for your reference. 

    First Graph corresponds to one of the first 3 ICs configured for continuous cycling. This is where we have problem now. Here all signals DRDY and SCLK  (DIN does not show up as it is continuous cycling) seem to be OK but DOUT seem to in high impedance all the time. In other two ICs DOUT is always low (graph is not shown here). What are the possible reasons for DOUT to be constant all the time in continuous cycling even when DRDY and SCLK are alright?

    With kind regards,

    Somayya

  • Hi Somayya Ammanagi,

    I am glad that you got the multiplexed device working properly.

    For the other three devices: are you using RDATAC or SDATAC mode? I don't see this command being sent in the logic analyzer plot, but perhaps it was sent before this image was taken. You might try using SDATAC mode if you are not already, just to see if you can get this mode working. This will require you to send the RDATA command after DRDY drops low. You will also need to respect the timing in the datasheet (pg. 6), specifically time t6.

    You mentioned that the desired data rate is 3750 SPS, but in the image you sent the DRDY pulses are ~2000 units apart (is that microseconds? What is the time scale on the logic analyzer)? At 3750 SPS and in continuous conversion mode, you should be getting pulses that are ~267 us apart. Can you confirm this is the case?

    Have you tried reading back your register settings to be sure the commands you are sending have taken effect?

    -Bryan

  • Dear Bryan,

    For other three devices we are using RDATAC. 

    The sequence of commands is as shown below.

    1) Issue SDATAC command on the falling edge of DRDY.

    2) Update STATUS REGISTER (hx00)  on next falling edge of DRDY followed by delay of 5 micro seconds

    3) Update ADCON REGISTER (hx00)  followed by delay of 5 micro seconds

    4) Update DRATE REGISTER (hxC0) followed by delay of 5 micro seconds

    5) Issue SELFCAL command on the next falling edge of DRDY followed by delay of 5 micro seconds

    6) Update MUX REGISTER (hx01)  on next falling edge of DRDY 

    7) Issue RDATAC command on next falling edge of DRDY followed by delay of 8 micro seconds

    8) Read DOUT (of 24 bits) 

    9) Continue to Read DOUT (of 24 bits) on falling edge of every DRDY.

    In the analyzer image, on x-axis what you see is samples (2000 * 0.13 ≅ 260 micro seconds). The DRDY shows DRATE set is correct.

    As mentioned in the the datasheet, I assume on power-on the device starts with RDATAC mode (and 30K SPS DRATE) during which it will not read any commands other than SDATAC and RESET. So, I issued SDATAC as first command and then other commands as in above sequence. According to that 3750 SPS DRATE is set effectively. That confirms me the effectiveness of early commands. In the Analyzer I can also SCLK corresponding DOUT but seems DOUT itself is dead.

    With kind regards,

    Somayya

  • Hi Somayya Ammanagi,

    Thanks for confirming some of the parameters of your system.

    Have you tried not issuing the RDATAC command in the sequence you just described, and instead wait for DRDY to drop low, issue the RDATA command, then issue 24 SCLKs? Remember to account for time t6 during this process. This was my suggestion from a previous post. Perhaps it is possible that you are having issues with RDATAC mode, and this will determine if that is the case.

    You could also try applying the behavior of the multiplexed ADC to the continuously converting ADCs. Since you know the multiplexed ADC is working correctly, you should be able to run that same firmware on another ADS1256 and get the same results. This will at least tell you if DOUT can toggle.

    Another thing to check: is there any possibility the FPGA is driving the DOUT pins on the ADCs, such that they cannot toggle? Or is there a possibility that these pins are shorted to DVDD somewhere on the board? I would check these possible concerns as well. 

    -Bryan

  • Dear Bryan,

    Yes we did try issuing the RDATA command in SDATAC mode, and found DOUT toggling at some instances. 

    As you suggested we will try with multiplexed mode for continuous conversion.

    How FPGA can drive DOUT on the ADCs? I cannot understand. I will check whether DOUT pins are by mistake shorted to DVDD.

    I have some specific questions as listed below:

    1) Why there could be inconsistency in DIN/commands effectively implemented for the same sequence and timing?

    2) Is issue of SDATAC command necessary before issuance of any other commands?

    With kind regards,

    Somayya

  • Hi Somayya Ammanagi,

    Can you explain in more detail what happened when you tried this:

    Yes we did try issuing the RDATA command in SDATAC mode, and found DOUT toggling at some instances.

    Did DOUT toggle randomly? Did you actually get good data out? At least you know that the DOUT is working on the ADCs

    It has been a while since I designed with an FPGA, but I recall that any pin could be configured as an input or an output. My question was about considering the possibility that the DOUT input pins on the FPGA were actually configured as outputs, and there could be contention on the DOUT line. Perhaps that is not a possibility with your specific implementation.

    Regarding your questions:

    Why there could be inconsistency in DIN/commands effectively implemented for the same sequence and timing?

    I am not sure I understand what your are specifically referring to here. Under what circumstances are you seeing inconsistencies? I thought at this point that none of the 3 continuously converting ADCs worked as intended. Are you saying that some work and some don't know?

    Is issue of SDATAC command necessary before issuance of any other commands?

    If the device is in RDATAC mode, then you either need to issue an SDATAC or RESET command first before issuing additional commands. When I have written firmware for the ADS1256 in the past, I usually issue a RESET command immediately after powerup just to be sure I am not in RDATAC mode. Then I initialize the ADC and start taking data.

    Have you confirmed that your timing between commands meets the requirements set in the timing table on page 6 in the ADS1256 datasheet? Specifically times t6 and t11? I cannot tell from the logic analyzer plots you sent so I will defer to you on this one.

    -Bryan

  • Dear Bryan,

    The major issues were related to SPI driver which was programmed for 24-bit read and write. While issuing 8-bit commands, the remaining 16-bits of read/write variable were kept zero. Since there are commands like WAKEUP which have all 8-bits zero, the issued dummy zeros were being misinterpreted as commands like WAKEUP.

    Now after modifying the SPI Driver for read/write of selected 8-/16-/24-bit variable, all the signals are consistent and now I am able to get data on all the 4 devices (continuous cycling on first three devices, each with one channel, and multiplexed cycling on fourth device for four channels).

    However, there are some issues in data acquired from the continuous cycling as shown in the Figure 1 that shows some spikes. On investigating this, it was found that though most of the time DRDY signal is clean (as in Figure 2), at times it looks corrupted (as in Figure 3).Figure 1

    Please suggest how it can be corrected?

    With kind regards,

    Somayya

  • Hi Somayya Ammanagi,

    Have you looked at this signal on a scope to see what is going on? Is it clean or does it have a lot of noise?

    DRDY is an output from the ADC, so there is no reason it should be toggling like that. In the third image I see what looks like two DRDY pulses that are about 40 units part. Assuming the timescale is the same as before, that is 40*0.13 = 5.2 us, or about 200 kSPS. The ADS1256 does not sample this quickly, so I cannot think of any circumstance where DRDY would toggle so quickly like that.

    I would check all of the communication signals with an oscilloscope and make sure they are clean.

    -Bryan

  • Dear Bryan,

    The signals look very clean on the oscilloscope as well as Vivado ILA. No significant noise.

    As DRDY is output from ADC and that to during continuous cycling, there are no other commands being issued, the DRDY signal is expected to be any glitch free. The DRATE is set to be 3750 SPS and the same is verified on the oscilloscope and ILA to be alright (DRATE period 267 microseconds: low for about 13 micro seconds and high for about 254 microseconds). But the unexpected DRDY spikes seen (when supposed to be low) in between are of high-width for about 2 samples i.e. 2*0.13 = 0.26 micro seconds. The SCLK period (0.52 micro seconds) was set to be 4 samples of CLKIN (0.13 micro seconds).

    For your information, when SCLK period (1.04 microseconds) was changed to 8 samples of CLKIN, the occurrences of unexpected DRDY spikes got reduced but observed (of same characteristics) even when DRDY supposed to be high.

    I will send you signals of the same take on oscilloscope for your reference.

    With kind regards,

    Somayya

  • Hi Somayya Ammanagi,

    Thanks, please send me the scope shots whenever you can.

    Is this happening on all three devices that are continuously converting, or just one?

    If it is happening on all three devices, do they all show some dependency on the SCLK period, where the number of spikes is reduced?

    -Bryan

  • Hi Bryan,

    Apologize for the delayed response.

    Below are the oscilloscope screen shots of the DRDY signal to show the noise levels on them.

    The issue of spikes in DRDY is appearing only in 1st and 3rd devices only not 2nd device.

    When the issue occurs in DRDY, correspondingly the disturbance in SCLK signal will show up in terms of  bit conversion taking only two CLKIN periods instead of CLKIN clock periods as shown in one of the previous pictures. But I have not observed any missing SCLK pulses like 23 instead of 24 pulses; may be it may not have shown up whenever we have observed.

    With kind regards,

    Somayya

  • Hi Somayya Ammanagi,

    Yes, my initial thought was that there some cross-coupling between the relative high frequency SCLK signal and the DRDY trace. This would make sense since there are no circumstances under which the ADC will output a DRDY pulse that is ~1 SCLK period. There was also some dependency on SCLK frequency, as the number of unwanted DRDY spikes reduced when you reduced the SCLK frequency.

    My best suggestion as this point is to review your board layout and see if there is any way that these signals could be coupling. If you have had to rework your board, I would also check for flux residue and improper solder joints.

    I would also try to capture the weird DRDY transitions on the scope, along with the SCLK signal, to see if there is any correlation.

    -Bryan