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 7 replies
  • Answers 1 answer
  • Subscribers 47 subscribers
  • Views 804 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.

Original question:

ADS131A02: Issue on communication

ADS131A02: ADC response issue

lovekush pratap
Prodigy 40 points
Part Number: ADS131A02
Other Parts Discussed in Thread: ADS131A04EVM

Hello TI,

I'm interfacing  c ADC with STM32F1 and operating in 24-bit word size.

I'm getting  READY response 0xFF0201 instead of  0xFF0200 when Software reset (0x001100) command is sent .

On hardware side M1 and M2 pins are connected to GND and M0 is connected to  IOVdd  and ADC_RESET is pulled up by 10k ohm resistor.

So is it OK to work with 0xFF0201 READY response?

If not, please let me know the solution for this .

  • 0
    TI__Guru 63086 points

    Hello Lovekush,

    Thank you for your post and welcome to our forum!

    The READY response word should be padded with zeros for word sizes greater than 16 bits. Therefore, 0xFF0200 is the correct response following a RESET command. Just to be clear, when you read the READY response, you are sending NULL (0x000000) on DIN, correct?

    Are M0, M1, and M2 connected to the supplies directly, or do you have a pull-up/pull-down resistor on each pin?

    Are you sure that you have configured the SPI correctly on your microcontroller? Since only the last bit is incorrect, I wonder if this is related to an SPI configuration issue. Please confirm that you are using CPOL = 0 and CPHA = 1.

    Best Regards,

  • 0 in reply to Ryan Andrews
    Prodigy 40 points

    Hi Ryan,

    Thanks for your response.

    Yes, I'm sending NULL (0x000000) on DIN.

    M0, M1, and M2 connection is shown in attachment. 

    Actually I'm configuring  ADC as GPIO instead of SPI. Is it fine way to configure?

    If no, please share the source code for configuration ADS131A02 using spi and for transferring the data.

    Best regards

  • 0 in reply to lovekush pratap
    TI__Guru 63086 points
    Hello Lovekush,

    Can you please confirm the CPOL and CPHA settings on your microcontroller SPI peripheral?

    Best Regards,
  • 0 in reply to Ryan Andrews
    Prodigy 40 points

    Hello Ryan,

    For now I am using bit-banging for SPI protocol. 

    So CPOL = 0 and CPHA = 0

    1- Let me know if there is any problem with using bit-banging for SPI.

    2- Share the code for configuration (NO bit-banging ) of ADS131A02 when I'm interfacing ADS131A02 ADC with STM32(standard libraray)

    Best regards

  • 0 in reply to lovekush pratap
    TI__Guru 63086 points

    Hello Lovekush,

    Please refer to the timing requirements and the switching characteristics in Table 7.6-7.7 as well as the diagram in Figure 1 for Asynchronous Interrupt Mode. As you can see, the rising edge of SCLK is used to shift data into/out of the ADS131A02. It is necessary to latch the data on the falling edge of SCLK is order to ensure that the data has settled and is read properly by the MCU/ADC. You cannot just bit-bang the interface and trust that it will always read/send data correctly.

    The source code for the ADS131A04EVM is not approved for release at this time, but there are other TI Reference Designs that use this device and have released their source code. One such example is http://www.ti.com/tool/TIDA-00810.

    Best Regards,

  • 0 in reply to Ryan Andrews
    Prodigy 40 points
    Hello Ryan,

    Can you provide this example source code with any STM32 MCU ?

    Thanks,
  • 0 in reply to lovekush pratap
    TI__Guru* 94285 points

    Lovekush,


    Sorry, but when we provide example source code, we do this for TI processors. I'm not aware of any code for any of our devices written for an STM32 MCU.

    Joseph Wu