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.

ADS131A04: How to read the translation results of ads131

Part Number: ADS131A04
Other Parts Discussed in Thread: TMS320VC5509A

Hi Team,

A customer is using TMS320VC5509a to control ads131a04 but was unable to find a clear description about how to read the translation results of ads131 in the datasheet so when they receive DRDY signal, they send NULL command (0x00000000) to read the ad result. However, the data are all zeros. The responses of the registers are all right when initialization

Can you help with this?

Thank you.

Regards,

Marvin

  • Hello Marvin,

    Thank you for your post.

    Is the customer able to see the READY response word after start up? Are they able to read/write registers?

    Please provide the state of the M0, M1, and M2 pins as well. 

    Regards,

    Ryan

  • Hi Ryan,

    Here is the response:

    "I can write registers and read what I want from them.
    I send 0x2200 to read the register STAT_1 and judge if the F_DRDY=1. Then the programme starts to receive AD results.
    The M0, M1 and M2 pins are all tied high to IOVDD.
    I use the Mcbsp of the TMS320VC5509A to simulate as spi to control the ADS131A04, and every frame of the transmission data has one word consisting of 32 bits.

    I have used stm32 to control ADS131A04 before. The STM32 completes the reception of conversion data by sending 0x00 24 times. However it seems no use to send 0x00000000 6 times with the dsp TMS320VC5509A."

    I hope this helps.

    Regards,

    Marvin

  • Hello Marvin,

    Is the customer actually using Hamming code bit correction and sending the calculated Hamming code bits with each device word? I'm not sure if an incorrect Hamming code would prevent the commands from being decoded properly. Can the customer try disabling the Hamming code by connecting M2 to ground?

    It may be more helpful to attached a screen capture of the SPI communication using a logic analyzer. This way we can validate the words being sent to / received from the ADS131A04 in the RREG frame. 

    I should also point out that we have a recommended initialization procedure in section 10.4 of the Application section of the data sheet. Key steps include unlocking the device and enabling the ADC channels before collecting data.

    Regards,

    Ryan

  • Hi Ryan,

    The customer do enable the Hamming code, but didn't send it with the device words from the dsp to the ads131. They think it should follow the 24-bit AD data when receive DRDY.  When writing the registers of the ADS131, they wrote RREG to read each register and all responses are right according to them. To read the AD results continually, the only one difference from the recommended initialization procedure in the code is that they didn't lock registers after wake up.

    The customer has no easy way to tie the M2 pin to GND at There is no logic analyzer available to them at the moment.

    Regards,

    Marvin

  • Hi Ryan,

    Additional information:

    The customer can use STM32 to control the ADS131A04, which works well and they think the output of the ADS131 is be right.

    The programming logic of the DSP is the same as the STM32. They have measured the signal (CLKX0, DX0, FSX0) sent by the DSP with an oscilloscope, which is as expected.

    I hope this helps.

    Regards,

    Marvin

  • Hello Marvin,

    I'm not sure what else to suggest here. Can we review the STATUS word contents when the customer is collecting data? Specifically, is the F_CHECK flag set?

    Regards,

    Ryan

  • Hello Marvin,

    I've confirmed with the design team that if Hamming is enabled, the hamming code including the checksum bits have to be sent to the device for the normal functions.

    Regards,

    Ryan