CCS/ADS8922B: Daisy-chain communication

Calvin Wallen IV

Part Number: ADS8922B
Other Parts Discussed in Thread: HALCOGEN

Tool/software: Code Composer Studio

Hello,

I am currently trying to receive conversion data from three ADS8922B set up with the daisy-chain topology. I've read the data sheet, looked at the timing diagrams and just want to make sure I'm thinking about this correctly before I pull all of my hair out trying to make this work.

Current setup:

1) CCSv7

2) HALCoGen 4.07

3) RM48L952ZWT

I am using the MibSPI1 module to send data to, and receive data from, the daisy-chained ADCs. All connections are configured as SPI functional, with the exception of the CS pin; which is configured as a GPIO.

From what I understand, the ADC should be in SPI-00-S protocol when first powered on (which is what I want to use).

Questions:

1) Does every control register have a default value of all 0's?

2) If yes, do I still need to configure any control registers even if I plan to use their default configurations?

- Regarding data transfer, I plan on sending/receiving 11 bits at a time using the SPI 16-bit shift register.

3) Is this a proper method of sending the commands I want to use?

4) Which register on the ADC actually holds a conversion and how am I supposed to use a RD_REG to acquire that value?

5) Once I have successfully sent a RD_REG, when should I expect the response?

I know this is a lot. I plan to post some very basic code ideas that I plan to attempt as well as what I observe with my logic analyzer with respect to what I have sent.

As always, thank you for your time and consideration

Calvin

over 7 years ago

0 Bryan McKay over 7 years ago

TI__Intellectual 1205 points

We are taking a look at this, and will get back to you soon.

0 Calvin Wallen IV over 7 years ago in reply to Bryan McKay

Intellectual 270 points

Bryan,

Any updates regarding communication with the ADS8922B?

Calvin

0 Bryan McKay over 7 years ago in reply to Calvin Wallen IV

TI__Intellectual 1205 points

Calvin:

Here is some basic information. On power-up, the ADS8922B resets all control registers to all 0's. If you like those settings, there is no need to configure the registers.

I am looking at your other questions.

--Bryan

0 Bryan McKay over 7 years ago in reply to Bryan McKay

TI__Intellectual 1205 points

Calvin:

More info, from p. 31 of the ADS8922B datasheet, provides some clarity about the 11-bits-at-a-time idea.

At the end of data transfer frame F:
• If the SCLK counter is < 22, then the IDR captured less than 22 bits from the SDI. In this case, the device
treats frame F as a short command frame. At the end of a short command frame, the IDR is not updated and
the device treats the frame as a no operation (NOP) command.
• If the SCLK counter = 22, then the IDR captured exactly 22 bits from SDI. In this case, the device treats the
frame F as a optimal command frame. At the end of an optimal command frame, the command processor
decodes the 22-bit contents of the IDR as a valid command word.
• If the SCLK counter > 22, then the IDR captured more than 22 bits from the SDI; however, only the last 22
bits are retained. In this case, the device treats frame F as a long command frame. At the end of a long
command frame, the command processor treats the 22-bit contents of the IDR as a valid command word.
There is no restriction on the maximum number of clocks that can be provided within any data transfer frame
F. However, as explained above, make sure that the last 22 bits shifted into the device before the CS rising
edge constitute the desired command.

In other words, assuming that the SPI words are being sent by the controller in 16-bit bursts, you should:
1. Pull nCS low.
2. Send 16 bits that contain 0b0000000000XXXXXX followed by a second 16-bits that contain 0bXXXXXXXXXXXXXXXX, where X is your cmd/addr/data bits.
3. Pull nCS high.

If your system allows 11-bit bursts, make sure the nCS pin remains low between them. Also, if more than 22 clocks are issued, make sure your communication is right-justified.

Reading data from a register (p.27 of the datasheet) involves sending a RD_REG command, which is a 22-bit frame, followed by pulling nCS high. Next, pull nCS low, and issue another 22 clocks. Bits D[21:14] will be the 8-bit contents of the register, followed by D[13:0] which are all zeros.

For reading the results of a conversion, you just need to pull nCS low and issue 22 clocks. Bits D[21:6], or the first 16 bits, will be your conversion result. (No need to issue a command, this is the default behavior of the device.)

I hope this helps!

0 Calvin Wallen IV over 7 years ago in reply to Bryan McKay

Intellectual 270 points

I plan to keep the default configurations, so that should be taken care of. What I have done up to this point is:

1) Set CONVST HI to start conversion
2) Delay to provide time for conversion to complete (I have used _delay_cycles(1) which is a little longer than what a conversion takes but it should be fine for now)
3) Set CONVST LOW
4) Set CS LOW
5) Provided 22*N clock cycles (in my case N = 3, so 66 cycles in total)
6) Set CS HIGH

I am definitely getting a response from the ADCs (observed on the saleae logic analyzer) which is great, but I still need to validate what that I am sending and receiving expected values. I am going to put another post up on the RM48/CCS thread, because I think I am not using the right approach when attempting to store the received data into a buffer.

Thank you for all of your time and effort!

TI respondents, saving undergrads one forum post at a time.

0 Bryan McKay over 7 years ago in reply to Calvin Wallen IV

TI__Intellectual 1205 points

Thanks, Calvin.

The RM48/CCS people should be able to help from here on out, but if you have any more analog or ADC questions, please let us know.

--Bryan

Data converters

Data converters forum

CCS/ADS8922B: Daisy-chain communication