• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 46 subscribers
  • Views 441 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.

ADS1298: Unable to see status word in data retrieval

Aiden Xu
Prodigy 10 points
Part Number: ADS1298

Tool/software:

Dear all,

I am validating a design that uses 4 ADS1298 in cascaded configuration. For all of the ADS1298, I can read their ID, read/write to config register 1,2,3 and config individual channels. 

However, when I put the devices in continuous data reading mode at 2KHz, there is nothing coming from the ADCs, not even the status word, though the data ready pin was toggling correctly at 2KHz. 

As documented in Section 9.4.1.3.1, the status word should have 1100 in the leading bits. But all the data from the ADC are 0s.

 

You can find my probed result (with Saleae Logic 1 software) in the attached. 

I appreciate any insight from you. Thank you very much.

Best,

Aiden

CascadedADS1298_4MHzSPI_2KHzDataRate.zip

  • 0
    TI__Guru 66256 points

    Hello Aiden,

    Thank you for your post. 

    I reviewed the logic analyzer capture that you shared (very helpful) and the communication looks mostly correct. One detail that caught my attention is that, following the register configurations, you are sending RDATAC without first sending the START command. In the beginning of your initialization routine, you send the STOP command, followed by SDATAC. Therefore, you must resume conversions using the START command prior to reentering RDATAC mode. However, I am curious why the DRDYn pin is toggling if conversions are not active...that I'm unsure of.

    Is there anything else in your setup which could be loading DOUT? I noticed during some register writes that SDO reads 0xCC during the first byte, but it should be 0x00. For example, see below when configuring Channel 1 for device 4:

    By the way, it is possible to bring all four CSn pins low when writing to the device or issuing a common command in case saving some time is of interest. Separate CSn signals are only required when reading from DOUT.

    Regards,

    Ryan

  • 0 in reply to Ryan Andrews
    Prodigy 10 points

    Dear Ryan,

    Thank you for the getting back to me. I have all the START pins tied together and controlled by a microcontroller. Just before reentering RDATAC mode, I pull the START pin HIGH to start conversion. That's why the DRDYn pin toggles at the right data rate.

    Is it okay to control the start/stop of conversion using both the START pin and START/STOP command, or I should choose one of them and stick to it? 

    I double checked the design and there is no other pins attached to DOUT other than the MISO pin from the microcontroller. So I don't think DOUT was loaded by other signals than the ADCs.  

    Regarding the data sent from the ADCs, am I correct to assume the ADCs should not return anything during read/write register commands and only reply with data after seeing a complete read/write command? I noticed that DOUT reads 0x60 during the first Byte of a channel register read. However, this only happens starting from reading the 2nd channel register. The ADC did not reply anything in the first Byte during the first channel register read.

     

    And thanks for the tip on writing to all the ADCs together!

    Best,

    Aiden

  • 0 in reply to Aiden Xu
    TI__Guru 66256 points

    Hi Aiden,

    If you plan to use START and STOP commands, I would recommend to leave the START pin tied low. If you bring START high, I would expect the device to resume conversions without any issue, even if you previously issued a STOP command via SPI. My only concern with the START pin is whether the part will consistently respond to STOP while the pin remains high.

    I noticed the repeated "0x60" during the first byte of subsequent RREG commands (following the initial one for channel 1). I think what's happening is the device is continuing to output the previous data loaded into the output shift register, which is the register setting for CH1. This behavior would be the result of setting CONFIG1[6] to 1b = "multiple readback mode." As a test, you can configure CH1 to a different gain setting and you should see the CH1SET register data repeated while sending the RREG command for CH2SET.

    Regards,

    Ryan

  • 0 in reply to Ryan Andrews
    Prodigy 10 points

    Thank you Ryan,

    I will test it asap. So do you think the reason I don't see any reading from the ADC is because of the "multiple readback mode"? 

    I thought the ADC should be put in "multiple readback mode" if the ADCs are in cascade configuration (as figure 66 depicted in section 9.4.2.1),

    Best,

    Aiden  

  • 0 in reply to Aiden Xu
    TI__Guru 66256 points

    Hi Aiden,

    I don't believe the multiple readback mode is related to not seeing conversion data. It's not imperative that you set this bit to 1b for multiple devices in Cascade Configuration. You can leave it as 0b (default), even though you are not using the daisy-chain input pin (in which case, the DAISY_IN pin should be tied to DGND). 

    To my earlier point, can you try issuing the START command before RDATAC instead of bringing the START pin high at the end of your routine? This is just to confirm the behavior is the same as expected.

    Regards,

    Ryan

  • 0 in reply to Ryan Andrews
    Prodigy 10 points

    Dear Ryan,

    Thank you for the suggestions. I confirm using START command only has the same effect as using the START pin. 

    After double checking the timing of the keep-out zone of 4 tCLKs, I realized the problem might lie in there. For example, after issuing a SDATAC command, I waited for 2us, which is in theory just enough but maybe with clock stretching or other factors, 2us wasn't enough in my case. After increasing the wait to 3us, the ADC behaved normally. I could configure the registers and see data with status word coming at the proper rate. 

    Thank you for the help! I will close this issue.

    Best,

    Aiden

  • 0 in reply to Aiden Xu
    TI__Guru 66256 points

    Hi Aiden - I'm glad you were able to figure out the timing issue. Let us know if you need help again in the future.

    Regards,

    Ryan