• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 45 subscribers
  • Views 1048 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

ADS1220: Data alignment problem on SPI bus of ADS1220

Christoph Ripcke
Prodigy 30 points
Part Number: ADS1220

I'm using an ADS1220 for quite time and I'm facing a really odd behavior.

My ADC is connected to a Cortex M0 with DRDY line. I tried reading out data using different ways.
  1. Set up ADC to continuous mode
  2. On falling edge DRDY interrupt trigger DMA SPI transfer for sending command and receiving data simultaneously. On DMA transfer complete I call my handler 

This method worked for quite some time without observed problems. After moving some of the DMA complete processing to timer based handler things turned bad. I observed that data maintained stable for some second and then gone haywire. In some cases it stabilized within between, in other test not. After testing I thought I had the debugger identified as source of the problem. Since it may stop clocks this could cause SPI communication timeouts. So I disconnected the debugger and transferred samples over CAN bus and recorded them. During 13 hours I read some 5 million samples which were all fine.

The day after, without having changed anything, the communication didn't remain stable not even for 10 seconds. After lot of attempts to fix I identified that switching to temperature measurement and back make things start going haywire with a high probability. When letting the ADC run only in either T or input mode data readings were fine.

Now I reconfigured the ADC to single-shot mode and read samples one by one, the transmission DMA has been removed in favor of the 4 byte transmission queue in the SPI controller. Reception is still done using DMA. What can be observed now is that the byte alignment gets mixed-up. After initialization the first reading is correct. Together with the read-out (interrupt based without RDATA command while DRDY is low) is send to bytes of zero and one START/SYNC command.

Upon the next interrupt, SPI fifo is flushed before DMA setup, I get one byte added before by MSB. On the following transfer I get the LSB shifted out first followed by an 0xFF and than the MSB. Following this scheme the expected result is rotated through 24 bit.

I was not able to confirm transients on the SCLK line, especially this would be odd because why should there always be 8 addition edges to shift data? After DMA transferred 3 bytes the SPI receiver is reported empty.

The fact that the code between the versions with different probability of occurrence hasn't changed, at least not in the driver level, totally puzzles me.
Has anybody an idea why I have this continuous shifting.
regards
Christoph
  • 0
    TI__Guru** 113765 points

    Hi Christoph,

    Welcome to the E2E forum!  Are you holding CS low all the time?  It sounds like you are getting a framing error due to the timing your are using.  There are two ways to retrieve the conversion results.  One is by directly reading by sending 24 SCLKs after DRDY transitions from high to low.  This method is shown in Figure 61 on page 37 of the ADS1220 datasheet and is best used when DRDY is monitored and the results read as soon as possible after DRDY transitions from high to low.  The second method for reading conversion results is by using the RDATA command.  This method is useful when DRDY is not monitored and a generic timer is used to periodically read the results.

    If you use a timer method, and change input channels you need to be very careful when the timer is reset.  The reason is based on two things.  The first is the internal oscillator may not be the exact frequency you are using for your timer and also the oscillator can drift.  The second reason is the conversion will restart following the register write.  If the timer trips and resets immediately, the timing will start to try to capture the results before the next update posts.  If you use the timer method as I have just described and following the example from Figure 66 on page 38 of the datasheet, you will eventually see a point where the data are corrupted as the new conversion result will not start until the WREG command has finished.

    You are attempting the correct method for troubleshooting whereby you use single-shot mode and wait for DRDY to transition from high to low and then send the RDATA command.  What will be returned is a mixed result.  On the first byte received, the (MSB) will appear first as this byte is already in the output buffer from the completed conversion result.  So when the RDATA command is sent, this MSB will be transferred.  Following the decoding of RDATA command, the last completed conversion result will be transmitted MSB-MID-LSB.  The transfer will look something like:

    MOSI = RDATA (0x10), 0x00, 0x00, START (0x08)

    MISO = MSB, MSB, MID, LSB

    It would seem to me that you are having some issues with data capture using DMA.  I would suggest using an oscilloscope, and better yet a logic analyzer to capture the communication to verify that what is being transmitted is what your code is showing following DMA.  If the transfer is using a word length greater than 8 bits (like 16 or 32) you also need to make sure that parsing of the data is taking place correctly in the receive buffers.  When using byte transfers it is easier.  The ADS1220 is always transmitting MSB first.  If you can verify that your code is working in single-shot mode, you could progress to continuous mode.

    Best regards,

    Bob B

  • 0 in reply to Bob Benjamin
    Prodigy 30 points

    Hello Bob,

    UPDATE:  Scope measurement confirmed 24 SCLK and data is 0x44, 0xD0, just as programmed. But there is no response on DRDY and CS is also measured as LOW

    thanks for the reply. Firstly, y never used the RDATA command (knowingly).

    What really puzzles me is that the approach did work on the method (which now is totally different due to debugging). Status/procedure is as followed:

    1. start HW
    2. configure all registers, use 2 KSPS and single-shot mode, TS=0
    3. every millisecond I sent a 0x08 START/SYNC command

    => data is read properly

    Instead of sending a START/SYNC I send a WREG to reg 1 with different baudrate (test purpose) and TS=1, CM=0.

    I chose to send the command after the 8th or after the 16th SCLK making sure that DRDY is low, i.e. data is available and conversion completed.

    In accordance with ...

    8.4.2.1 Single-Shot Mode
    In single-shot mode, the device only performs a conversion when a START/SYNC command is issued. The
    device consequently performs one single conversion and returns to a low-power state afterwards. The internal
    oscillator and all analog circuitry (except for the excitation current sources) are turned off while the device waits
    in this low-power state until the next conversion is started. In addition, every write access to any configuration
    register also starts a new conversion. Writing to any configuration register while a conversion is ongoing
    functions as a new START/SYNC command that stops the current conversion and restarts a single new
    conversion. Each conversion is fully settled (assuming the analog input signal settles to its final value before the
    conversion starts) because the device digital filter settles within a single cycle.

    I expected a new conversion would start when sending 0x44, 0xC2 which it didn't. If I try this with CM=1 the baudrate would not change.

    What am I doing wrong. Currently I'm ignoring the read back data and I have another odd SPI related behavior. I flush the SPI
    peripheral and write three bytes to the FIFO. I get 2 pulses on the bus.

    Any idea?

    regards

    Christoph

  • 0 in reply to Christoph Ripcke
    TI__Guru** 113765 points

    Hi Christoph,

    Can you send me your scope plots for me to review?

    The section 8.4.2.1 begins with 'In single-shot mode, the device only performs a conversion when a START/SYNC command is issued.'  So you cannot rely on the written portion below that statement to automatically start a conversion when the registers are written.  What this section is really stating is that if after the START/SYNC command has been issued and you reconfigure the ADS1220 during an ongoing conversion, the conversion will restart with the new configuration information.

    There are some very unique circumstances where the ADS1220 has not completely gone to a low-power state where the register write may trigger a conversion, but you cannot rely on this condition to always take place.  Also, the START/SYNC command has some other internal commands that must be issued for a valid conversion result.  So, when in single-shot mode you should always issue the START/SYNC command to start the conversion from the low-power state.

    You should be able to read the conversion result directly and send the WREG and START/SYNC command at the same time.  The transmit data would look like 0x44, 0xD0, 0x08 when receiving the 3 bytes of conversion data.  Please send me scope shots of this transaction.

    Best regards,

    Bob B

  • 0 in reply to Bob Benjamin
    Prodigy 30 points

    Hello Bob,

    after some 12 years I did debugging by scope again. I can confirm what you have said above and adding a START/SYNC after reconfiguring the ADC helped.

    thanks for being my sparring partner

    regards

    Christoph