• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Subscribers 46 subscribers
  • Views 310 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.

ADS130B04-Q1: Protocol Communication issues

Martín Martín Meirás
Prodigy 10 points
Part Number: ADS130B04-Q1

Hi everyone,

I have recently been integrating this ADC differential converter IC and struggling with reading and writing registers via SPI. I am using a Rpi to communicate with it.

My setup is the following.

CLKIN -> GND

SYNC_RESET -> Pullup to VDD

DRDY -> NC

CS      <- Connected to my Rpi SS

SCLK  <- Rpi Spi Clk output

DIN    <-- MOSI Rpi

DOUT --> MISO Rpi

I have analyse the signals with an oscilloscope and I am pretty sure they are ok. SPI is configured in mode 1, Most significant byte sending and 24 bit word size. Frequency of master clock has been changed form 10 Kbps to 1Mbps without success. Below you can find the communication outputs from Rpi and inputs also.

NULL command data response:
DATA BYTES 0xff54 - Padded 0x00
DATA BYTES 0x0000 - Padded 0x00
DATA BYTES 0x0000 - Padded 0x00
DATA BYTES 0x0000 - Padded 0x00
DATA BYTES 0x0000 - Padded 0x00
DATA BYTES 0xac79 - Padded 0x00


RESET Output message:
DATA BYTES 0x0011 - Padded 0x00
DATA BYTES 0x0000 - Padded 0x00
DATA BYTES 0x0000 - Padded 0x00
DATA BYTES 0x0000 - Padded 0x00
DATA BYTES 0x0000 - Padded 0x00
DATA BYTES 0x0000 - Padded 0x00


RESET Read message:
DATA BYTES 0x0511 - Padded 0x00
DATA BYTES 0x0000 - Padded 0x00
DATA BYTES 0x0000 - Padded 0x00
DATA BYTES 0x0000 - Padded 0x00
DATA BYTES 0x0000 - Padded 0x00
DATA BYTES 0xf71a - Padded 0x00

UNLOCK Output message:
DATA BYTES 0x0655 - Padded 0x00
DATA BYTES 0x0000 - Padded 0x00
DATA BYTES 0x0000 - Padded 0x00
DATA BYTES 0x0000 - Padded 0x00
DATA BYTES 0x0000 - Padded 0x00
DATA BYTES 0x0000 - Padded 0x00


UNLOCK Read message:
DATA BYTES 0x0655 - Padded 0x00
DATA BYTES 0x0000 - Padded 0x00
DATA BYTES 0x0000 - Padded 0x00
DATA BYTES 0x0000 - Padded 0x00
DATA BYTES 0x0000 - Padded 0x3d
DATA BYTES 0xc680 - Padded 0x02


------------------------------------------


NULL command data response:
DATA BYTES 0x0500 - Padded 0x00
DATA BYTES 0x0000 - Padded 0x00
DATA BYTES 0x0000 - Padded 0x00
DATA BYTES 0x0000 - Padded 0x00
DATA BYTES 0x0000 - Padded 0x00
DATA BYTES 0x7b8d - Padded 0x00


WAKE UP Output message:
DATA BYTES 0x0033 - Padded 0x00
DATA BYTES 0x0000 - Padded 0x00
DATA BYTES 0x0000 - Padded 0x00
DATA BYTES 0x0000 - Padded 0x00
DATA BYTES 0x0000 - Padded 0x00
DATA BYTES 0x0000 - Padded 0x00


WAKE UP Read message:
DATA BYTES 0x0533 - Padded 0x00
DATA BYTES 0x0000 - Padded 0x00
DATA BYTES 0x0000 - Padded 0x00
DATA BYTES 0x0000 - Padded 0x00
DATA BYTES 0x0000 - Padded 0x00
DATA BYTES 0xf71a - Padded 0x00


------------------------------------------


NULL command data response:
DATA BYTES 0x0500 - Padded 0x00
DATA BYTES 0x0000 - Padded 0x00
DATA BYTES 0x0000 - Padded 0x00
DATA BYTES 0x0000 - Padded 0x00
DATA BYTES 0x0000 - Padded 0x00
DATA BYTES 0x7b8d - Padded 0x00


Mode Register Write Output message:
DATA BYTES 0x6100 - Padded 0x00
DATA BYTES 0x2902 - Padded 0x00
DATA BYTES 0x0000 - Padded 0x00
DATA BYTES 0x0000 - Padded 0x00
DATA BYTES 0x0000 - Padded 0x00
DATA BYTES 0x0000 - Padded 0x00


Mode Reg Read message:
DATA BYTES 0x6b00 - Padded 0x00
DATA BYTES 0x2902 - Padded 0x00
DATA BYTES 0x0000 - Padded 0x00
DATA BYTES 0x0000 - Padded 0x00
DATA BYTES 0x0000 - Padded 0x7b
DATA BYTES 0x8d00 - Padded 0x05


------------------------------------------


NULL command data response:
DATA BYTES 0x0500 - Padded 0x00
DATA BYTES 0x0000 - Padded 0x00
DATA BYTES 0x0000 - Padded 0x00
DATA BYTES 0x0000 - Padded 0x00
DATA BYTES 0x0000 - Padded 0x00
DATA BYTES 0x7b8d - Padded 0x00

Answers to NULL command are the only ones that return the default status register as 0x500. However when mode register is set, the answer to this command should be 0x4200 instead  of 0x6b00 and also some bytes in the zero padded bytes have been found for no reason. Even though the answer is wrong ( based on the datasheet SBASAD2 of November 2021), the status register after that command is not changing even though Register CRC has been enable (bit 13), also CRC type has been changed to ANSI (bit 11).

Any clue would be appreciated.

Regards,

Martín

  • 0
    TI__Guru 57296 points

    Hi Martin,

    Thank you for your post and welcome to our forum.

    (disregard my initial reply as input CRC is disabled by default).

    In Line 89, it looks like you are enabling the Register Map CRC, but not the SPI CRC. Did you mean to enable both?

    Would it be possible to capture these consecutive frames on a logic analyzer to see the entire sequence? It's a little unclear whether each block of "DATA BYTES" pertains to a data write or a data read (i.e. lines 87 - 93 look like a WREG frame on DIN. Are lines 97 - 102 the response read on DOUT? Is this the same frame or the next frame?).

    A scope or logic analyzer capture would be helpful. We can also import a Saleae capture file directly and review the entire sequence of commands if you also use a Saleae.

    Regards,

    Ryan

  • 0 in reply to Ryan Andrews
    Prodigy 10 points

    Hi Ryan,

    Thank you for your help.

    First of all I understood the Register Map CRC as a CRC of the configuration registers of the ADS130B04 device but I am not so interested in it until I finally make it to communicate with the device correctly. Do you mean then that without the SPI CRC the Register MAP should not be enabled? And if so, can you tell me why?

    I'm currently unable to make the frames capture with the logic analyzer, I will post them as soon as I can.

    Regarding the data in the initial post. As I read in the datasheet the device answeres to a command in the next frame but for me it was answering in the same frame of the command, therefore I opted for sending a command and then a NULL command.

    That said, the structure of the file is data sent by the Rpi to ADS130B04 device (that is data that the ADS130B04 device receives in its DIN), output in the same frame (data the ADS130B04 device sends over the DOUT ) and then the answer of the device to a null command (that is the data of the next frame).

    Hope this helps to understand the data. Summarizing, Null commands are not printed so "NULL command data response" stands for the answer of the ADS130B04 device to a null command.

    I will post the captures ASAP.

    Regards,

    Martín

  • 0 in reply to Martín Martín Meirás
    TI__Mastermind 20795 points

    Hi Martin,

    Ryan is out of office for the remainder of the week. Let me see if I can help out in the meantime.

    The SPI CRC and Register Map CRC are completely independent from each other. You can enable either, both or none of them.
    I also tried to follow your protocol above. Some of the responses definitely do not make sense and you should also not see any bits in the padded area. The first step to debug this would really be to look at the communication on a scope or logic analyzer.

    Are you executing the protocol you show above in that order and without any gaps between commands?
    E.g. after a RESET command you should not immediately talk to the device because the device needs to complete the reset process. There is also no need to unlock the device after reset because the device is unlocked by default. A WAKEUP command would not be required after reset.

    Regards,
    Joachim Wuerker

  • 0 in reply to Joachim Wuerker
    Prodigy 10 points

    Hi Joachim,

    Thanks for your reply. There are only 50 ms between each group of commands (NULL command response, Command Output message and Command Read message).

    Also, there is no logic command sequence in the provided data. My purpose was to give the more information the better. Thats why I tried random commands.

    My initial approach was to send a reset command, then wait 50 ms, write registers with the desired configuration, read the registers and then read the ADCs data to check the configuration is the desired one. But as this was not happening I just tried some commands to see if the answers were correct.

    To add some more info, I also tried with another unit of the device and another Micro to send the commands over SPI, just in case the unit was wrong, but I had no success. It had the same behaviour.

    Hopefully, on monday I will have some oscilloscope captures.

    Regards,

    Martín

  • 0 in reply to Martín Martín Meirás
    TI__Mastermind 20795 points

    Hi Martin,

    thanks for the clarification. Your described sequence: "send a reset command, then wait 50 ms, write registers with the desired configuration, read the registers and then read the ADCs data to check the configuration is the desired one." would be correct.

    Let's hope the scope captures will provide some more insight. At least the response to a NULL command seems to be correct. To me that seems like something with your data on DIN is not quite right. Have you confirmed that your SCLK idles low?

    Regards,
    Joachim Wuerker

  • 0 in reply to Joachim Wuerker
    TI__Mastermind 20795 points

    Hi Martin,

    have you managed to look at the SPI signals with a scope in the meantime or did you solve the communication issue already?

    Regards,
    Joachim Wuerker

  • 0 in reply to Joachim Wuerker
    Prodigy 10 points

    Hi Joackim,

    Thanks for all your support, finally my hw colleague came to the conclusion that it was due to a hw issue.

    After that hardware fix, we finally were able to communicate and get the ADC data successfully.

    Regards. 

  • +1 in reply to Martín Martín Meirás
    TI__Guru 57296 points

    Hi Martin,

    Thank you for the update. We're glad that you found and resolved the issue.

    Please let us know if you have any additional questions in the future.

    Regards,

    Ryan