ADS1248 conversion always reads 0x7FFFFF

Hi Frank,

If you are in SDATAC mode, then you must use RDATA to retrieve the conversion.  This is a 4 byte sequence where you initially send the RDATA command (either 0x12 or 0x13) followed by 3 NOPs (see figure 78 of the datasheet.)  During the NOPs is when the data is output on the DOUT pin.

A write command, WREG, to three registers is a 5 byte sequence.  The first byte is the WREG command that includes the first register written (in this case 0x40) followed by the number of registers written less one (3 -1=2) 00x02, followed by the contents of the 3 registers.

If you plan on reading the data with RDATA and then writing to three registers the total communication transaction would be 9 bytes.

It would appear from the scope shot that the command for SDATAC was not correctly acknowledged, and you are overdriving the input by either not having the reference on/connected or the inputs are exceeding the full-scale range.

Best regards,

Bob B

Bob: many thanks for your time. I am aware that in SDATAC I must use RDATA, which I note in my original post "issuing SDATAC and RDATA".

My understanding is that RDATA requests a read of the conversion data, but the firmware must wait for DRDY to be asserted before attempting to read the conversion data. You suggest reading immediately after RDATA without regard for DRDY. Is that correct?

I do understand that WREG for 3 registers is a 5 byte process and that is indeed what my firmware is writing, exactly as you indicate.

Why does the scope shot indicate that SDATAC was not correctly acknowledged? If SDATAC was effective at initialization, and RDATA issued afterward, one should see DRDY followed by a conventional read of conversion data, exactly what the scope shows EXCEPT that the 3 bytes of conversion data is 0x7FFFFF.

While it is possible that I am overdriving the hardware inputs for MUX0 readings, my firmware cycles through two MUX0 readings, then one MUX1 temperature diode [ambient sensor] and that is of course internal to the ADS1248 and cannot be overdriven.

Something else is wrong.

Hi Frank,

Let me take a step back a moment as I may have jumped to the wrong conclusion.  From the scope picture you posted I don't see the RDATA command nor do I see any register write data. This led me to believe that the device was being communicated to incorrectly. When issuing RDATA the last completed conversion results are loaded to the output register. If you change the mux and start a new conversion the previous results are going to be read when you complete the transaction because you've already made the request. The device does not wait for a new conversion.

Once you have written the registers, have you read them back to verify the contents? This would make sure you are communicating to the device correctly. For your situation you can issue the RDATA command then read the results. At the same time you are reading you can issue the WREG command and the data. This will shorten the total transaction length as the device communicates full-duplex. It is much easier to understand the communication transaction if it is not split into two sections over a period of time, as in the case given.

If you are reading full-scale, then you need to make sure of the conditions of my previous post are not causing the problem.

Best regards,

Bob B

Frank,

One other thing I might point out. SDATAC does not stop conversions. It only stops the results from automatically being posted to the output register.  DRDY will toggle after conversion is complete in either mode. To stop conversions the START pin is taken low which powers down the part. If the START pin is low you cannot read or write registers.

If you post your schematic I can help verify that it is connected properly. What reference are you using? What are your register settings?

Best regards,

Bob B

Hi Bob,

I believe if you examine magenta line 3 on the scope trace, you will see all ones for the five NOPs sent out after DRDY and CS then indeed the 0x12 which corresponds to RDATA.

I have performed a write/read/compare via WREG/RREG and see correct values, using 0, 0x55, 0x33 and 0xFF. I am reasonably confident that write/read is reliable.

To repeat our implementation scenario, we will be using the ADS1248 to continuously read six temperature sensors and the one on-chip ambient temperature sensor. My code initializes SYS0, SDATAC then RDATA. The code then enters a state machine that waits for the falling DRDY edge, asserts CS, waits 2 ms, sends a series of NOPs to get the results of the previous conversion, WREG to change MUX0 and MUX1 to the next sensor in sequence, RDATA, removes CS, ad infinitum.

For test purposes, I have modified the code to select the ambient temperature sensor in MUX1 at initialization time, then RDATA, then the state machine does everything described above except not the WREG to change the sensor selection, retaining only the RDATA after the NOPs before removing CS. It "works" except that even the ambient temperature sensor reads back 0x7FFFFF. I presume it is "impossible" to overdrive the ambient temperature sensor, since that is internal to the ADS1248.

The reason I abandoned RDATAC is because of the need to continuously switch sensor selections. Sample TI code indicated that collection must be stopped before doing any WREG or RREG. Since I had to do WREG to change the sensor selection, it was more efficient to SDATAC at initialization and then simply RDATA after each WREG change.

Thanks again for your time.

Bob,

I understand that SDATAC does not stop conversions, merely stops DRDY indication that a conversion is ready to be read.

Currently we have START [and RESET] tied high. I am surprised to read that setting START to zero powers down the part. I was under the impression START solely controlled whether or not conversions were being made, but WREG and RREG were still operational. Not true?

ADS1248EVM to dsPIC30F4013 Demo board connections

Jumpers on ADS1248

J1: 1-2

J2: 1-2

J10: ALL ON

J5, J6, J13: No jumpers

J14: No connection

Hi Frank,

I think there is a little confusion about how the part works with respect to DRDY.  Unless the START pin is low (power down) or the device is in RESET the DRDY transition that signals the end of the conversion cycle is always on the DRDY pin no matter if SDATAC or RDATAC mode is used.  If you never read from the ADS1248 you will see DRDY pulse from low to high to low at the selected data rate.

The configuration on the EVM appears correct, but how are you connecting the supplies for both AVDD and DVDD?  If AVDD is correctly applied, you should see 2.048V on the REFP test point (referred to AVSS.)

You do not need to issue a SDATAC to communicate to the part as long as the communication transaction completes within one complete conversion cycle.  If you are using the slower data rates you should not have a problem.  The EVM firmware uses SDATAC as the registers are always written as a block, and there is no way to guarantee when the block is written as the firmware uses a RTOS.  This can be problematic if higher data rates are selected.

The RDATA command does not start a conversion cycle, so there is no need to send the command ahead of time.  Changing the mux will restart the conversion so that the next completed conversion will be valid.

If you should continue the SDATAC mode, the write/read sequence could be as follows:

DRDY goes low, start cycle pulling CS low:

CS should return high signaling the end of the transaction.  DRDY goes high at the first rise of SCLK, and stays high until conversion cycle completes and then goes low and the process would repeat.

If you use RDATAC mode, you can use the same sequence but skip the RDATA command.

Best regards,

Bob B

Bob: after our hardware guys took a very close look, they discovered that certain signals and power lines were not properly connected. Once they were corrected, the part then began giving "real" conversion results rather than simply pegged at 0x7FFFFF.

I am a little nervous about a few of your comments above. My observation is that after the ADS1248 asserts DRDY, and after the host asserts CS, as soon as the host then begins putting out clocks, e.g., sending NOPs, the ADS1248 immediately starts sending the 24 bits of conversion data, regardless of what command the host is outputting, NOP, RDATA, WREG, whatever. Yet you recommend above starting with an RDATA and disregarding the first received byte. In my brief experience, that first byte will be the conversion MSB. Not true?

On the other hand, in the example command sequence you provide above, will the RDATA get the conversion for the previously selected mux?

Thanks for your time.

Frank,

I'm glad to hear you are able to get data.  RDATA always gives out the last result based on when RDATA is issued.  The description of your experience with the data does sound to me as if the device is still operating in RDATAC mode and not SDATAC.  As a side note, SDATAC does not take effect until after the current conversion completes.  In other words, if a conversion cycle has started and then SDATAC is issued, that cycle's conversion data will post automatically to the output register.  After that particular result has posted SDATAC will take effect and no more results will be automatically posted to the output register unless RDATAC is issued or the device is reset. 

If you are seeing that data is still being posted to the output register, then SDATAC has not been interpreted correctly by the device.

Let's say you are running RDATAC mode, do you need to issue RDATA to get the results? The answer is no.  In RDATAC mode the last conversion results will be in the output register ready to be retrieved whether you have read the previous conversion results or not.  Once DRDY asserts low, you can read the data.  If you want to just read out the results you can issue a NOP for each byte read out.  If you want to change the configuration for the next conversion, you can issue the WREG command and data instead of the NOP to read/give a command at the same time.  Of course you can also send a longer transaction by sending the three NOP for the data retrieval and then send the WREG command and data.

Any time you change the state of CS from low to high and back to low, the communication for the SPI is reset and any previous command will be terminated.

Best regards,

Bob B