Because of the holidays, TI E2E™ design support forum responses will be delayed from Dec. 25 through Jan. 2. Thank you for your patience.

  • State Resolved
  • Locked Locked
  • Replies 8 replies
  • Subscribers 45 subscribers
  • Views 1110 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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/7/8 Communication issues

MC
Prodigy 180 points
Other Parts Discussed in Thread: ADS1246

Hi,

There are some issues regarding the SPI data comunication on ADS1246/7/8. Datasheet is not clear about the number of CLKs needed with some commands:

SYNC - 16 CLKs with CS low or 2 x 8 CLKs with CS low on each byte (Figure 74)?

RREG - 16 CLKs with CS low or 2 x 8 CLKs with CS low on each byte/command? Also, the register read cycle  (Figure 80) also need 16 CLKs?

WREG - There must be one frame only with 24 CLKs (figure 80) or two frames after the command has been issued?

Regards,

MC

  • 0
    TI__Guru** 113765 points

    Hi Vasco,

    CS must remain low throughout the entire communication transaction.  Every time CS toggles state the communication is reset.  You can send in byte increments as long as CS remains low.

    For the WREG command, there is two command bytes followed by data.  The number of data bytes will be determined by the number of bytes you stated in the second command byte.  In the case of writing 1 register, the WREG sequence would consist of the WREG command byte (that includes the register being written) followed by the byte that includes the number of bytes being written minus 1 and ending with the byte of data.  This is a 24 bit transaction where the CS must remain low throughout.  The 24 bits of data can be broken up into 3 bytes, which is often the easiest way for a micro to transfer data as the buffer is often 8 bits in size.

    Best regards,

    Bob B

  • 0 in reply to Bob Benjamin
    Prodigy 180 points

    Hi Bob,

    Consider the following example to read the BCS register (00h). Correct me if the following steps are not right:

    1) CS Low

    2) Send 1st command byte: RREG plus BCS register = (0010 | 0000) -> 8 CLKs

    3) Send 2nd command byte: just one value to read so zero should be sent = (0000 | 0000) -> 8 CLKs

    3) Sent one NOP to receive the register value -> 8 CLKs

    4) CS High

    I espect to receive the reset value of BCS which is 01h but nothing is returned...

  • 0 in reply to MC
    TI__Guru** 113765 points

    Hi Vasco,

    The best way to trouble shoot communication issues is with an oscilloscope.  This helps to determine that you are using the correct clock polarity and phase for the communication.  If you can post a scope shot I can help evaluate it.  Another thing, you need to make sure the SPI clock is not running too fast.

    Another possible issue is with reading conversion data instead of the register as the device defaults to RDATAC mode which automatically places the conversion result in the output register.  When reading and writing registers I place the device into SDATAC mode first.  This then stops the automatic posting of the results in the output register.  RDATAC can be problematic if the new results are being posted in the middle of a register operation.

    Another consideration is that you cannot read/write registers unless the START pin is high.

    Best regards,

    Bob B

  • 0 in reply to Bob Benjamin
    Prodigy 180 points

    Hi Bob,

    Thank you for your fast reply and helpfull considerations. I already use a oscilloscope to check the communication signals. It is everything fine with respect to clock speed, polarity, phase, I'm sure about that. Also I take into account the necessary delays and pulse durations accordingly the datasheet specs.

    I found that the converter does not startup in RDATAC mode. The problem is in fact around the START pin. With this pin is HIGH I can access the registers otherwise I cannot access them via the SPI commands WAKEUP(/SLEEP). I'm getting trouble with this software equivalents to control the device....

    Regards,

  • 0 in reply to MC
    TI__Guru** 113765 points

    Vasco,

    The START pin controls the power down state of the device.  With the START pin low the analog portion of the device is completely powered down.  Most of the digital functions are also powered down.  The Start pin will override any SPI Sleep function.  Wakeup will not work if Start is low.

    To control the Sleep state via SPI, then you must have Start high and then write the Sleep command.  If you issue the Wakeup, the device will wakeup from this combination.  Be aware that CS must be low the entire time while using the SPI commands.  If you you bring CS high, the device will automatically wakeup.

    Best regards,

    Bob B

  • 0 in reply to Bob Benjamin
    Prodigy 180 points

    Hi Bob,

    What a tricky converter :)  On page 37 of the datasheet is stated that " When the START pin is low or the device is in sleep mode, only the RDATA, RDATAC, SDATAC,
    WAKEUP, and NOP commands can be issued", so I thought that WAKEUP could be issued on those conditions.

    Also, you said that " If you bring CS high, the device will automatically wakeup"...is it right? It would make sense that CS low (active low) wakeup the device and CS high put him in sleep mode.

    Regards,

    MC

     

  • 0 in reply to MC
    TI__Guru** 113765 points

    Hi Vasco,

    Yes some of these more complex devices can be a little tricky.  The statement on page 37 is a little bit confusing.  What might have been a better way to write it is to say, 'if the device is in sleep mode, whether it be by Start pin low or by command, only certain commands will continue to function.'  I totally understand your confusion with the Wakeup command as a part of the command list that continues to operate in the sleep state.  You can think of the Start pin as the master and the SPI Sleep/Wakeup as sub-master commands.  In other words, without Start high there can be few commands that work as it is still asleep.  You can attempt to wake the device, but it is still in sleep mode because the Start pin has priority.

    As far as the CS remaining low throughout the Sleep command period, the way the state machine operates is that when the CS toggles state the SPI bus is reset and the state machine is configured to wake the device for normal operation.  That is just the way it was designed.  If the Sleep command is used, it takes effect following the completion of the current conversion.  The Wakeup commands is strictly based on the rising edge of the eighth bit.   Neither command relates directly to CS.  From my understanding the designer assumed that if CS went high following the Sleep command the desire for other operations and commands could be issued such as a WREG command.  For this to happen the device needs to be awake.  So that the state machine is fully aware of the operational state it was thought to be best to always be in a known state for the device then to be strictly controlled by software command in an unknown state.  If you think about this long enough it does make some sense from a state machine viewpoint.

    Best regards,

    Bob B

  • 0 in reply to Bob Benjamin
    Prodigy 180 points

    Hi Bob,

    I understand your explanation. Regarding the digital part of the device everything is working fine. I hope my doubts help others users as well. Also, I think that another document revision would be convenient. Thanks a lot for your clarifications.

    Best Regards,

    MC