Difficulties Interpreting Data Sheet- How to Make ADS1246 perform a single conversion

I have corrected the sequence-- still looking for reasons why it does not appear to work.

Here is the proposed sequence of steps--but they do not give good results--- values alternate from correct, to correct-20000 counts, to correct, for each cycle. The SPI interface has been proven out with a mixed signal oscilloscope, but there is the possibilty that DRDY is doing something unexpected.

1. Assert Reset. Assert Start, Release Chip Select.  (These signals are isolated by a dual supply level translator which works well and prevents latch up)

2. Apply Power to VDDA and VDD- we wait about 500 us for voltage to exceed minimum VDD and VDDA data sheet values

3.  Release Reset

4. Wait 17ms for ATD SPI interface to become ready.

5. Immediately transmit to ATD command SDATAC-  (Advice from tech support-- "we always do this".) The SPI transmission is framed with chip select.

6 Transmit to ATD commands to select PGA and sample rate over the SPI bus. The SPI transmission is framed with chip select.

7. Release Start Line

8. Pulse Start Line

9. Set up interrupt detection logic to detect falling edge of DRDY.

10. On falling edge of DRDY, transmit SPI Commands RDATA, NOP, NOP, NOP. All four commands are framed by a chip select. The 24 bit result is gathered during the transmission of the 3 NOP's.

11. Remove power.

12 Repeat procedure in 1 second.

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

Does anyone see a problem in the above sequence?

W HS,

Welcome to the forum!  It looks as though your procedure is correct.  Can you send us some actual data that you have collected?  A large sampling size of data would be helpful.  Actual hex code would be better than decimal.

Best regards,

Bob B

 The first picture below is an overview of the digitization. The top noisy blue line is DRDY

The next line down is the decoded MOSI signal

The next line down is the decoded MISO signal

From the first MOSI transmission to DRDY low, we have approximately 50 ms for a sample rate of 20sps.

 The second picture below ZOOMS IN on the first SPI commands:

16- STOPDATA C

43-WREG starting at SYS0

00- only 1 register written

42- 20sps + gain of 16

The third picture below zooms in on end of process-- collecting the data after DRDY has gone low. 

12- RDATA command (ATD is sending 0's  simulatneously with the SCLKS)

FF-FF-FF Nops to collect data

ATD sends 0A-27-26.

 These are the conversion results in base 10, each separated by 1 second:

41615
665198
41613
665224
41611
665218
41611
665202
41618
665202
41617
665215
41616
665215
41617
665191
41614
665230
41610
665195
41617

As you requested, observed conversion results in hex...

Here is a picture showing  BAD conversion results being sent over the SPI bus. This would rule out any kind of bugs between capturing the ATD result and sending it to a PC.

  A good result is 665181 which is consistent with 17mv.

Here is another piece of information:

The bad conversion results occur when the ADS1246 takes around 220mS to do a conversion. For reasons unknown, the sampling rate seems to alternate from 20 samples per sec to 5 samples per sec on alternate conversions. It would appear that programming control register SYS0 is not having an effect on the chip every other cycle.

We have verified that the correct initialization information is being sent on the SPI bus at the start of  these "bad" 220mS conversion cycles.

W HS,

Thanks for all the great information.  The reason I asked for the hex codes was to see if there was a bit shift pattern.  There is and it is 4 bits.  Basically I think you have discovered your problem and next is to find the cause.  The write command is not happening and the system is in default with 5 sps and gain of 1.  This is the bit shift of 4 bits when your data is normally gain of 16.

So now we know the problem, now what do we need to do to fix it?  Usually this is related to some form of timing issue.  It is interesting that this appears every other time.  Is it possible that something is slightly different in procedure between the two events?  Like the actual delay after the RESET event?

As you have very specific timing, you may be able to get away from the SDATAC command.  Though we generally don't advise this it may work in this case as the device starts after RESET and your timing is very specific.  There may be a couple of overall power benefits as well.  I would try a couple of small adjustments to your procedure.  Once the device comes out of RESET, write the SYS0 register with the speed and gain changes.  Then place  the START line low, and don't pulse it.  Wait for DRDY to go low, then read the data directly without sending the RDATA command (just read 3 bytes of data.)

If you still have problems with the data, I would look specifically at the delay time after RESET.  Also, you might monitor CS to make sure that it doesn't go low before RESET delay period has completed.

Best regards,

Bob B

Bob for the moment I have reverted back to 5sps in order to meet a milestone.

Can you tell us if the Reset Pin will override the VDD monitor reset? In other words, could an internal reset still be active even though we release the reset pin 350uS after VDD and VDDA have reached minimums.

Looking at the schematic below, we have an RC filter on VDDA. We do not see a problem with the time delay from this filter on VDDA (5 tau = ~ 24uS).

W HS,

I don't see anything wrong with your procedure in relation to RESET.  I have to go back to the data.  I find it incredibly interesting that the results alternate every other time.  That screams to me like something is different every other startup.  I would look again at the communication control lines and verify that the communication is absolutely identical each time.  I would also look at something in the code that may be toggling versus something that is reset each time.  It could be something like a counter value not getting reset.

If the read always works, but the write doesn't, then there is something that happens at the beginning.  It could be a glitch on the CS or SCLK line.  After reviewing the scope shots again I did notice that the SCLK goes low only shortly before CS goes low.  Is it possible to set this line low sooner like before RESET is pulled high?  Toggling CS before the first communication would reset the SPI bus just in case a glitch on the CS line messed things up, so you could try that.

Best regards,

Bob B