ADS1292: Data acquisition failure issue by RDATA command with START=Hi by pull-up resistor

Hello,

Has my question been sent to you?  If yes, could you please give me your comments today(7/24) since it has already passed 5 days?  If not, could you do by tomorrow since E2E forum will undergo maintenance from 7/26(Wed)?

Best Regards,

Yoshikazu Kawasaki

Hi,

The app engineer was out for business travel, shall get back to you around 7/28.

Hi,

Please suggest customer to compare their PCBA schematic with the EVM schematic to see if there is any significant error -

https://www.ti.com/lit/ug/slau384a/slau384a.pdf?ts=1690320407112&ref_url=https%253A%252F%252Fwww.ti.com%252Fproduct%252FADS1292

Page 49 ~ 56.

Please make sure to do proper reset.

and

Could customer successfully read the ID register?

datasheet 8.6.1.1 ID: ID Control Register (Factory-Programmed, Read-Only) (address = 00h)

Bits[7:5] REV_ID[7:5]: Revision identification

Bit 4 Reads high

Bits[3:2] Reads low

Bits[1:0] REV_ID[1:0]: Revision identification

And, write&read back the register settings?

------------------after above is verified and work correctly-------------------

See if customer could set registers values like below -

They should be able to see two test signals(square wave) in both channel -

Thanks

Hello ChienChun-san,

Thank you very much for your advice.

I suppose I've found the mechanism of the issue.  Would you please tell me if it makes sense?

My customer's settings are as follows.

1. Fixed START=Hi by pull-up resistor.

2. Read the data by RDATA command.

3. Asynchronous read out with /DRDY.

4. No /DRDY signal when they get incorrect data.

5. Incorrect data regardless of before/after conversion.

The input data change on their system and if their system issues RDATA command, the internal digital filter coefficient needs to change according to the input data after the RDATA command.  Since it takes 3 tDR for the filter to settle to the new value as shown in the datasheet, /DRDY disappears after the RDATA command and it takes 3 tDR for the filter.  Therefore when /DRDY isn't asserted, you can't tell what the data will be because it is unknown/uncertain by the incorrect filter coefficient.  They need to wait for the correct data until the 4th /DRDY assertion.  Am I correct?

Best Regards,

Yoshikazu Kawasaki

Suggest to follow SPI troubleshooting&debug instructions
e2e.ti.com/.../2868427

then try
8.5.1.12 Single-Shot Mode first
once above timing are all verified, move on to
8.5.1.11 Continuous Mode
Thanks

Hello ChienChun-san,

Thank you very much for your advice again.

They don't have any issues on AFE1 that they read data synchronized with /DRDY at 8kSPS, but do on AFE2 that they do asynchronously at 500SPS.  Could you please tell me if my understanding shown in my previous thread is correct or not?

> Could customer successfully read the ID register?

Yes, they can read data incl. ID register.

> Suggest to follow SPI troubleshooting&debug instructions

They do operation based on the figure 44 shown in the datasheet.  They don't use RDATAC mode, but do RDATA though.  Their system is CPOL=0 and CPHA=1, so it should be OK for ADS1292.

Best Regards,

Yoshikazu Kawasaki

Hi,

It's not clear to me from the schematic how they connect the two ADS1292 to the host/master.

From their schematic, 

AFE#1's CLKSEL is pulled up to 3V, so its own internal clock oscillator is used

AFE#2's CLKSEL is pulled up to 3V, so its own internal clock oscillator is used

Each one runs its own clock cannot be guaranteed to be synchronous. Is this what customer want?

Both START pins are pulled up to 3V, but do both START controlled by the host/master at exact the same time or not?

The Host/Master need to decide whether to pull up or low of both START signals/pins at the same time or not.

Are both DOUTs go to different pints of the host/master, i.e. DOUTs never touch/share?  If yes, then the customer is&can treat each ADS as its own independently.

So, the two devices may not be guaranteed exactly synchronous because they run their own internal CLK, and both clocks may or may not sync by chance.

----------------------------------

I don't quite understand what you mean by "3. Asynchronous read out with /DRDY."  Could you explain more?

Do you mean read data from each AFE independently use their own /DRDY independently?

--------------------------------------------

Also, for this "They don't have any issues on AFE1 that they read data synchronized with /DRDY at 8kSPS, but do on AFE2 that they do asynchronously at 500SPS."

Could you explain what do you mean by
"synchronize" with /DRDY on AFE1

and

AFE2 that they do "asynchronously" 

Maybe please tell me how exactly they want to read from each AFE instead of using "synchronous" or "asynchronous" will be easier to understand.

-------------------

If they want to operate two devices in two different data rate, then their master/host may need to adapt differently as many timing depends on the data rate tDR, especially /DRDY, just to give some but not all example -

Figure 48. Settling Time

Figure 49. Continuous Conversion Mode

and 8.5.1.2 Serial Clock (SCLK)

"the minimum speed needed for the SCLK depends on the number of channels, number of bits of resolution, and output data rate."

"For example, if the ADS1292R is used in a 500-SPS mode (2 channels, 24-bit resolution), the minimum SCLK speed is approximately 36 kHz"

----------------------------------------

so, for now, my suggestion might be,

Since they can already read data from AFE#1 with 8kSPS correctly, then try the following -

1. Try to read data from AFE#2 with also 8kSPS, this should require little or no change of the code.

2. Try to set/configure AFE#1 to 500SPS and make their host/master to adapt to read AFE#1 with 500SPS.

If both above could be implemented and verified, then they will have code and more clues how to ready AFE#2 with 500SPS.

Thanks

Hello ChienChung-san,

Thank you very much for your continuous support and I'm sorry for not replying to you soon.

> Each one runs its own clock cannot be guaranteed to be synchronous. Is this what customer want?

Yes, that's what they're aware of.

> Both START pins are pulled up to 3V, but do both START controlled by the host/master at exact the same time or not?

Their system doesn't use START pins since those are fixed to high level as you know and uses RDATA command instead.

> Are both DOUTs go to different pints of the host/master, i.e. DOUTs never touch/share?  If yes, then the customer is&can treat each ADS as its own independently.

Actually, it shares the same pin, but the data is controlled by CS1 signal from the MCU, either AFE#1 data or AFE#2 data.

 > So, the two devices may not be guaranteed exactly synchronous

They intentionally controls ADCs asynchronously.

----------------------------------

> I don't quite understand what you mean by "3. Asynchronous read out with /DRDY."  Could you explain more?

> Do you mean read data from each AFE independently use their own /DRDY independently?

The AFE#1 uses /DRDY and read the data synchronously at 8ksps and there is no issue on AFE#1.  The AFE#2 doesn't use /DRDY and read the data asynchronously and it has unexpected data issue.  AFE#2 works at every 2ms by using the 500sps clock.  However their system issues RDATA, but sometimes gets wrong data.

--------------------------------------------

> Could you explain what do you mean by
> "synchronize" with /DRDY on AFE1

> and

> AFE2 that they do "asynchronously" 

Their system monitors /DRDY from AFE#1(DRDY signal on their schematic) when reading data, but doesn't do the one from AFE#2(DRDY2 signal on their schematic).

> Maybe please tell me how exactly they want to read from each AFE instead of using "synchronous" or "asynchronous" will be easier to understand.

MCU monitors DRDY(/DRDY from AFE#1)

-> Read the data when DRDY=0

MCY doesn't monitor DRDY2(/DRDY from AFE#2)

-> Read the data.

> 1. Try to read data from AFE#2 with also 8kSPS, this should require little or no change of the code.

> 2. Try to set/configure AFE#1 to 500SPS and make their host/master to adapt to read AFE#1 with 500SPS.

Changing the sampling frequency doesn't fix the issue.  I mean the issue doesn't have dependency on the clock frequency.  Their system has the issue on AFE#2 whatever the clock frequency is.

They'd like to have timing charts when their system can or can't read the data using the RDATA command.  Do you have such ones you can provide to the customers?  If you don't, would you please check if I create ones?

The issue seems to happen after their system issues RDATA command, so I suppose the issue would be simple.  When RDATA command is issued, it takes 3tDR for the internal filter to settle, so the issue they see is just the behavior of ADS1292.  Am I correct?

Best Regards,

Yoshikazu Kawasaki

Hi,

I will get back to your around or before 8/17

Hi,

Timing chart/requirement is provided in ADS1292 datasheet  page 11 and page 45, page 48, 49.

And, an SPI timing troubleshoot post link was provided in the earlier post.

Thanks

Hello ChienChun-san,

Thank you very much for your comments.  Would you please check the the attached and give me your comments for my 3 questions shown in the attached in red to confirm if my understanding is correct?

ADS1292_RDATA_Timing.pptx

Best Regards,

Yoshikazu Kawasaki

I may get back to you around 8/22

Thanks

Hi,

1.

Settling Time or tSETTLE dependencies are shown and listed in page 44 Figure 48 and Table 13, you will have to check your calculation and equation based on the DR and tMOD and tCLK and CLK_DIV settings -

2.

To know when and why the /DRDY is high, please check the following conditions -

a. Once START is pulled high, DRDY is also pulled high.

b. DRDY is an output. When it transitions low, new conversion data are ready. The CS signal has no effect on the
data ready signal. The behavior of DRDY is determined by whether the device is in RDATAC mode or the
RDATA command is being used to read data on demand.

c. The DRDY output is used as a status signal to indicate when data are ready. DRDY goes low when new data are available.

d. DRDY is pulled high at the SCLK falling edge. Note that DRDY goes high on the first
SCLK falling edge regardless of the status of CS and regardless of whether data are being retrieved from the
device or a command is being sent through the DIN pin.

e. DRDY returns to high on the first SCLK falling edge.

Figure 46 shows the relationship between DRDY, DOUT, and SCLK during data retrieval (in case of an
ADS1291, ADS1292, and ADS1292R with a selected data rate that gives 24-bit resolution). DOUT is latched out
at the SCLK rising edge. DRDY is pulled high at the SCLK falling edge. Note that DRDY goes high on the first
SCLK falling edge regardless of the status of CS and regardless of whether data are being retrieved from the
device or a command is being sent through the DIN pin.

3.

The settling time (tSETTLE) is the time it takes for the converter to output fully settled data when the START signal is pulled high.

Settled data are available on the fourth DRDY pulse. Settling time number uncertainty is one tMOD cycle.

Therefore, it is recommended to add one tMOD cycle delay before issuing SCLK to retrieve data.

so, If begin reading the data by using the START opcode command or pull the START pin to high, the data is more valid&settled after the 4th /DRDY pulse, and it's recommended to wait one more tMOD cylcle delay after the 4th /DRDY pulse before issuing SCLK to retrieve data.

Thanks

Hello ChienChun-san,

Thank you very much for your comments.

1. CLK_DIV=0 and DR[2:0]=0b110, so iMOD=4xtCLK=4x1270ns=8.68us(max).  Then iSETTLE=68xtMOD=590.24us(max).  Am I correct?

2. You showed several cases of /DRDY, but which one do you think the root case would be for this time?  Actually the cases you showed don't seem to show my customer's case, remaining /DRDY=Hi followed by RDATA opcode.  Therefore I suppose it might be different from the ones you showed.

3. Thank you for pointing me the one tMOD cycle delay.  Please see attached and give me your comments if you have, especially page 7 showing the summary of my understanding for the timing to read correct data from the RDATA command.

ADS1292_RDATA_Timing_Summary.pptx

4. I have another question, unclear sentence in the datasheet.  It says in 8.5.1.10 Settling Time that "Refer to Table 10 for the settling time as a function of tMOD", but I don't think the table 10 shows the settling time.  Would you please tell me exactly what the sentence means?

Best Regards,

Yoshikazu Kawasaki

Hi

Regarding to

1. Customer needs to check and verify their own math and calculation.

2. The best way to know the root cause is to get an EVM and customer could compare their timing diagram with the EVM.

Does customer have ADS1292R evaluation kit/evm?  This is the best and most efficient way to V&V and compare the timing with EVM.

So far, has customer been able to always read the 8.6.1.1 ID: ID Control Register (Factory-Programmed, Read-Only) (address = 00h)  correctly?

3. Please refer to above.

4. "Refer to Table 10 for the settling time as a function of tMOD".  I think it's a typo, it refers to Table 13.

Thanks

Hello ChienChun-san,

Thank you very much for your comments again, but I'm expecting you to comment like "Yes, your understanding is correct" or "No, your understanding isn't correct because ..." so that I can tell my customer the root cause and how it can be fixed.  Would you please tell me in such ways?  I understand #4 is a typo and it should be fixed when the datasheet is updated next time, but I'm not sure if my understandings are correct for #1 and #3.  I'd like to get your comments on #2 because they don't have the EVM and it takes time to work on it.  I need to ask you the root cause anyway regardless they'll check on the EVM or not to confirm it.

Best Regards,

Yoshikazu Kawasaki

Hello ChienChun-san,

I forgot to comment if they can read the ID control register correctly.  Yes, they can do that.  They can read all the registers except the converted data after RDATA command is issued.

Best Regards,

Yoshikazu Kawasaki

Hi,

The following is the ADS1292 SPI timing diagram when SPS is set to 1000SPS and acquire Internal Test Signal of 1 Hz Square Wave

START(CH1)

/DRDY(CH2)

/CS(CH3)

SCLK(CH4) period around 80~82 ns that meet the datasheet timing requirements tSCLK SCLK period  at least 50 or 66.6 ns

To show how DOUT is clocked/latched by the falling edge of SCLK-

DOUT(CH1)

/DRDY(CH2)

/CS(CH3)

SCLK(CH4) period around 80~82 ns that meet the datasheet timing requirements tSCLK SCLK period  at least 50 or 66.6 ns

Which aligns&matches with ADS1292 datasheet figure1 and figure 46 -

i.e. /DRDY pulls down by ADS, SCLK's rising edge triggers/align with the 1st edge of DOUT and then the 1st falling edge of the SCLK clock/latch the DOUT data bit, and also triggers the /DRDY to pull up high.

It's highly suggested customers could get a ADS1292R EVM.

Thank.

Hello ChienChun-san,

Thank you very much for providing the plots.  I understand the plots align with the datasheet, but I'm not asking such thing.  I'm doing if my understandings are correct and what the root cause would be for my customer's issue.  Would you please give me your comments for each of my question by Yes or No?  If no, would you please tell me why my understanding isn't correct?

1. CLK_DIV=0 and DR[2:0]=0b110, so iMOD=4xtCLK=4x1270ns=8.68us(max).  Then iSETTLE=68xtMOD=590.24us(max).  Am I correct?

2. You showed several cases of /DRDY, but which one do you think the root case would be for this time?  Actually the cases you showed don't seem to show my customer's case, remaining /DRDY=Hi followed by RDATA opcode.  Therefore I suppose it might be different from the ones you showed.

3. Thank you for pointing me the one tMOD cycle delay.  Please see attached and give me your comments if you have, especially page 7 showing the summary of my understanding for the timing to read correct data from the RDATA command.

Best Regards,

Yoshikazu Kawasaki

1. When CLK_DIV = 0, tmod = 4 tclk,  And, when DR[2:0]=110, the settling time will be 68*tmod; thus, 68*4tclk = 272 tclk, but with "uncertainty is one tMOD cycle", "uncertainty is one tMOD cycle",  "Therefore, it is recommended to add one tMOD cycle delay before issuing SCLK to retrieve data."

so, it could be 68+1 tmod = 69 * tmod = 69 * 4 tclk = 276 tclk.

2. It's hard to say the root cause as there could be many factors involved and require more depth debug and/or troubleshooting; that's one of the reasons to suggest customer to compare with the EVM schematic and timing.

If don't worry about the ADC code to voltage conversion, is customer able to plot the internal test signal in DC or Square wave?

Do their SCLK's falling edges clock each SDOUT bit correctly?

NOTE: SPI settings are CPOL = 0 and CPHA = 1.

Are they still using 2 ADS1292R together?

Could they try only single ADS1292R and turn off all the Respiration related function and features and 
1. do internal short test and observe the signal data/plot should be quiet?

2. plot the internal test signal in DC or Square wave?

Note that for ADS1292R, if the respiration function is enabled, CH1 cannot be used for ECG and there will be more noises.

Thanks,

Hello ChienChun-san,

Thank you very much for your continuous support.

#1:I understand.

#2/#3:Actually, their system works completely as expected except the converted data after RDATA is issued.  It also means the relation between SCLK and DOUT is normal.  They still use 2 ADS1292, but the CS signals are controlled separately and they aren't enabled simultaneously.

Please forget all the information I gave you and let me ask you a question differently.  It a system configures START=Hi(fixed) and convert the data by RDATA command, how long it would take to read the converted correct data?  I suppose it would be like the attached, but am I correct?

Best Regards,

Yoshikazu Kawasaki

Hi,

Conversion and RDATA are two different things/actions.

------------------------------

Conversion is started/launched/activated by the START, so once either START pin is Hi or START command is sent, the conversion starts.

Maybe they could first check if they could see similar timing diagram shown above in Figure 49.

e.g. in the continuous conversion mode, does the /DRDY come in the consistent period of tDR?

and/or

Figure 46 and 52,

Pull down /CS when seeing /DRDY's falling edge

then, issue SCLK with the 1st rising edge, and after tDOPD from the 1st SCLK rising edge, starts seeing the DOUT showing.

then, observe on the1st falling edge of SCLK, the /DRDY rises, and the SCLK can continue clocking&latching the DOUT using falling edges upto 72 bits.

--------------------------------------------------

RDATA or RDATAC is only for "to read data" not for "To START conversion".

Are you referring to RDATA  or RDATAC?  These two are slightly different-

For RDATAC, RDATAC opcode only needs to be sent once, and there is timing constraint on the tSCLK that depends on the DR selection and the tCLK - 

For RDATA, does/can customer match the timing diagram shown in

Figure 1 and Figure 53 RDATA usage?

 E.g. make sure the SCLK falling edge clock/latch the DIN when issue RDATA command(opcode).

Also, note that the 1st 24 bits from DOUT are status bits not signal data bits.

Thanks

Hello ChienChun-san,

Thank you very much for your comments again.

They don't use RDATAC(Read Data Continuous), but does RDATA(Read Data).  They confirmed all the timings for SPI which means the timings shown in Figure 1 and 53 are OK.

Yes, they understand it uses SCLK falling edge for DIN.  As I mentioned earlier, one of the ADS1292 in their system work as expected, but the other one doesn't.  The main difference of the usage between those is synchronous(no issue) or asynchronous(incorrect data issue) to /DRDY.

Yes, they understand the 1st 24bits are status bits.

Please let me ask you a questions again.  Would you please tell me how long it takes to read the expected/correct data by RDATA(not RDATAC)?  Will it be available at the 1st /DRDY=Low after the RDATA command?

Best Regards,

Yoshikazu Kawasaki

Hi,

"Settled data are available on the fourth DRDY pulse.",  so not the 1st /DRDY pulse.

By the way, may I ask why customer cares so much about the non-settled data in such short period of time( in clock cycles scale)?

Regardless any ADC, it will always takes sometime(clock cycles) for signal or data(regardless whether it's ECG signal or not) to settle and/or stable, so even if they see/acquire some unsettled data for some clock cycles, this should not affect the signal of interest in the long run(i.e. after some clock cycles of the settle time).

They could ignore those unsettle data/signal even if those unsettled data stream into their master/host buffer or memory.

Or, does customer want to literally and diligently chop&dump those unsettled data every time?  It might be a laborious and not so practical approach unless there is very good and necessary reason for doing this.

 Thanks

Hello ChienChun-san,

Thank you very much for your comments again.  I understand my understanding is basically correct.

> By the way, may I ask why customer cares so much about the non-settled data in such short period of time( in clock cycles scale)?

They asynchronously read the data as I mentioned and they sometimes do incorrect data, so they just would like to know the mechanism why it is.  Actually, they also know they read the same data since their system reads the data periodically.  If they know when the settled/correct data is available, they can ignore the incorrect data.

> Or, does customer want to literally and diligently chop&dump those unsettled data every time?

No, they don't.

Best Regards,

Yoshikazu Kawasaki

Hello ChienChun-san,

I attached a figure here showing my understanding from your comments and the datasheet.  Please correct me if I'm wrong.

Best Regards,

Yoshikazu Kawasaki