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.

ADS1246 SPI issue

Other Parts Discussed in Thread: ADS1246

Hi,

We have 7 devices on a SPI interface which is controlled by an MSP430. From the data sheet we expected that when the data ready output was asserted (low) then this would be cleared by the SCLK only for the ADC with the chip select active. This is not what we observe. The DRDY is returned high for all the ADCs on the bus at the first SCLK even though the chip select is high for six of them.

I have attached a couple of logic analyser plots showing this behaviour. These show the SCLK and DRDY and CS for three of the ADCs. There is also a signal named DRDY_COOLANT_NAND that indicates to the MSP430 that DRDY is present for the ADC selected. As you can see, this only occurs for the first one that is read.

We have the START tied high so that the ADCs are free running and CLK tied low so that they are clocked internally. The sampling rate is 20 samples per second and we are trying to read them all in a group every 250ms.

  • Mark,


    This may take a little digging into. If you have the data file that generated this plot, could you please post it? I have a Saleae also, with the software to open the file.

    I'll have to get an EVM to test this out. I should be able to check the behavior of /DRDY with /CS high. There's a couple other things I may be able to check as well.

    Give me a little time and I'll look into this issue.


    Joseph Wu
  • Mark,


    I checked into the DRDYn's behavior and it looks like that even with CSn high, the DRDYn responds by rising on the first falling edge of SCLK (thus making it difficult getting data out immediately after selecting the device).

    You could add some tri-state buffers to gate the SCLK to the individual devices, but I'm guessing that since you already have a system, it would be difficult add.

    However, there are still things to try. It just depends on how you are collecting the data from the individual ADCs.

    If you are running all devices at the same time and want to collect the data in a batch, I can think of two things that would help in cleanly getting the data out from device to device. First, use the SYNC command or pin to make sure that the devices are all synchronized together (naturally this assumes that all devices share the same clock. This way devices will have data that is ready at the same time. Second, when reading out the device, use 25 SCLKs so that pulls the DOUT high. When CSn is high, DOUT will be tristated high impedance. However when CSn is low, the DOUT will remain high if the data is not ready. If DOUT is low, then a new data has been put onto the output register and is ready to be clocked out. This was recommended to another customer at one point - I'll need to check on it, but I wanted to get you this information quickly.

    Either way, if you can describe what you are trying to do, we may be able to come up with an easy solution.


    Joseph Wu
  • Joseph,

    We are assuming that to sync all the ADCs we have on our board, we would need to pull the CS line for all ADCs low, then issue the sync command. Due to the design of our board, we can only pull the CS line of one ADC low at a time. We are providing the chip selects via a 3 to 8 line decoder. As such, I’m guessing this option is not available to us.

     

    On our circuit, we have the START line tied high meaning the ADC is continually performing conversions. We have it configured to convert at 20SPS, so every 50ms a new conversion is available. Previously we have had the ADCs in ‘Read data continuously’ mode, which is the reason we were looking for the Drdy line. Occasionally though, the conversion read out of the output register has been corrupt. We now suspect, as per the earlier posting, this is because the Drdy line was not asserted and we read from the output register while the conversion was being loaded in. Our alternative solution is to stop continuous read, and just issue the read data command (RDATA) when we require a sample. As the START line is tied high, the ADC should be continuously performing conversions every 50ms, so when we issue the RDATA command, we read out the latest. Also, we are assuming the RDATA command does not need to wait until the Drdy line is asserted and will just return the most recent conversion. This avoids our previous problem with corruption when the ADC is copying the conversion into the output buffer.

    Are our assumptions correct?

    Regards

    Mark

  • Mark,


    Yes, to issue the SYNC command to all the devices, you would need to pull CS low for all the devices to send the command. Without the CS, the SPI decoder is held in reset.

    With the device in RDATAC mode and not using /DRDY as an interrupt, you could get a new data while reading out the device. The data read would be corrupted. You would get the concatenation of the first part of the first data read and the first part of the new data.

    If you use the alternate solution of issuing the SDATAC, you would stop the DOUT from updating with each new read. In this case you would read out the most recent data while the ADC is continuously converting, you wouldn't need to wait for the /DRDY conversion. That should eliminate the corrupted data problem.

    Do you use the internal oscillator on the ADS1246, or do you use an external clock? With the internal oscillator, you have a +/-5% variation in the internal oscillator frequency. In this case, you may need to wait a little longer to ensure that you have a new data to read out.


    Joseph Wu
  • Hi Joseph,

    I’m a colleague of Marks, working on the same project, and if possible, I would like to ask a few more questions on the ADS1246. From your previous advice, we are now successfully reading the ADC every 250ms, but now we have a new requirement where we need to switch the ADC burnout source on and off (as we have to continually monitor for open circuits). The requirement is such that we need to check for open circuit and if not, sample the sensor, both within the 250ms window. As such, we configure the registers to enable burnout source, wait 75ms (SPS is set to 20), then issue the RDATA command. This gives us the readings necessary to determine open circuit. We then reconfigure the registers to disable burnout, wait 75ms and issue the RDATA command again. Unfortunately though, for this sample, we are observing a reading that looks like the ADC is still in burnout with the sensor attached or the output register still contains the old sample.

    After some experiments, we discovered that by extending the time from reconfiguring the ADC to disable burnout, to reading the next sample to about 150ms, the reading is correct. So it looks like the output register is only updated after about 150ms from completion of reconfiguring the registers. As the SPS is set to 20, we would have expected the conversion to only take 50ms.

    To be absolutely sure the conversion has restarted after reconfiguring the registers, we issue the SYNC command, but this doesn’t seem to make any difference.

    Do you have any ideas why it is taking so long for the conversion to be loaded into the output register?

    One other point worth noting is we have the START signal tied high. Are there any issues associated with having START high when issuing the SYNC command?

    Calum
  • Calum,


    First, there shouldn't be any issues tying the START signal high. I know of many applications that do this and there shouldn't be any problems using the SYNC because of it.

    Additionally, there shouldn't be any extra time associated with loading the conversion onto the output register with the change of the burnout current source. Since the burnout current source control is in the MUX0 register, the ADC mux change should occur soon after the completion of the WREG to used to set them. This should trigger a reset of the digital filter and start a new conversion. If the data rate is set to 20 SPS, you could track /DRDY and see if there is a pulse 50ms after the WREG completion just to make sure that device received the change.

    One thought that I had would be that you have extra capacitance in your measurement circuit that is slowing down the transitions switching from channel to channel.

    As an example, let's say you are measuring an RTD with a ratiometric measurement using a current shunted through the RTD and a reference resistor. The RTD burns out, so that the current no longer flows through the reference resistor and the reference is at 0V. If you switch channels to another RTD and there is a very large capacitance across the reference resistor, then the first thing that will happen is all of the excitation current will be used to fill the capacitance. Starting out, the RTD voltage would be fine, but the reference would take a long time to settle. An accurate measurement would be delayed because the voltages haven't settled to the final value.

    I don't know what you are measuring, so I used the above as an example. If you are able to share a schematic, I'd be happy to look it over and see if there are any possible issues. If you are unable to share a schematic, I might need you do describe in detail what you are measuring and how it is done.


    Joseph Wu