ADS8528: Issue Writing to the Configuration Register

Hi Stephen,

Can you include a schematic of the ADS8528 connections and zoom in on the serial transfer a little?  If you can get just the write sequence, that would be great.  Also, to read back the registers, instead of writing 0x480083FF, try 0xC80083FF.  To 'set' bit 30, bit 31 needs to be set as well.

Hello Tom,

I have attached three screen captures: The complete view, zoomed into the write, and zoomed into the read.

As shown in the capture, what was mentioned in the post at http://e2e.ti.com/support/data_converters/precision_data_converters/f/73/t/243723.aspx. didn't work for me.

Stephen

The Complete view:

Zoomed in to the Write:

Zoomed into the Read:

Hello Tom,

I forgot to add the schematic showing the connections to the ADS8528.  Please see below.

Stephen

Hi Stephen,

Thank you for the additional detail!  Can you please change the polarity of your SCLK so that it dwells high while its inactive and let me know if that resolves your problem.

Hello Tom,

I am using the TMS320F28335 uC.  My application is using the McBSPA, McBSPB and the SPIA serial ports to communicate with three ADS8528s.

the McBSP port uses the CLKXP and CLKRP registers to determine the clock polarity and I currently have them set as follows:

CLKXP = 0  // Trasmit data on rising edge

CLKRP = 0 // Receive data on falling edge

I also have CLKSTP = 2 // SPI mode with no clock delay.

What McBSP register do I use to make SCLK dwell high?

Stephen

Hello Mark,

I was able to get SCLK to initially dwell high.  However, I am still having the same issue. Please see images below.

Stephen

Closeup View (write config):

Complete View:

Hello Tom,

In my last post I forgot to describe the current McBSP clock stop mode and polarity configuration:

CLKSTP = 3

CLKXP = 1

CLKRP = 1

Do you need any more information from me?

Stephen

Hi Stephen,

In the screen shots you've sent, it looks like you are reading out conversion results.  Do they seem reasonable?  You can try changing the DAC output values to adjust the reference and see how that impacts the conversion results.  Since you have all channels going through SDOA, you would need to continue reading past the conversion results to read out the configuration register details.

Hello,

I have attached a logic analyzer output below.  I decided to send just C800083FF and not 880083FF.  I don't see the configuration value in output.  The first data item 9001 doesn't seem right since the 2s compliment of 9001 is 6FFF, which is > 12bit.  Also, I won't know what the data is if I I'm not able to set/read the configuration data.

Does a start conversion reset the ADC internally?

Should I see the 080083FF after 9 reads?

Stephen

Hello Tom,

Previously, I didn't check the DDR1 and DDR2 registers since I assumed (:( never assume) they would have the same values as shown on the logic analyzer.

After five 32-bit reads, the Mcbsp DRR1 and DDR2 contain the correct configuration value.  It seems the busbee logic analyzer output is showing the data shifted to the left by 1, i.e. 0x900107FE shifted left is 0x480083FF.

Does the ADC channel pointer resync internally each time a conversion is started/completed such that channel A0 always comes out first, A1 next and so on?

Stephen

Hi Stephen!

It sounds like you are making progress!  Yes, if the CONVSTS are tied together, you will always read out CHA0 first.

Well..kind of.

I can get the busy signal to work, but the INT signal isn't working.

My config register setting is set to 0x080083FF (Note: I actually set the register to 0xC80083FF when I set it).  Shouldn't that be the correct setting?

The INT's polarity setting is working, i.e. the INT output goes high after I set the config register to 0x0C0083FF.

Stephen

Hello,

I wasn't able to get the INT signal to work, so I decided to use the negative edge of the busy signal, which works.

The problem I am having now is that some of the data read from the ADC doesn't match what measured using an oscilloscope.

Can you please verify I am computing the voltages correctly (I am using the 2.5V internal reference and 4*VREF):

Positive Counts:

Actual Voltage = ADC Count * 4* 2.5V/4095

Negative Counts:

Actual Voltage = 2's compliment of ADC Count * 4 * 2.5V/4095

Also, it looks like some of the channels are using 8 instead of 4 in the equation above.

Stephen

Hello Tom,

I believe the issue with incorrect values being read from the ADC has to do with an incorrect ADC configuration.  

For the two ADCs that are connected to McBSPa and McBSPb, the ADC data is half of what is expected.  For the ADC that is connected to the SPI port, the ADC data is between 14% to 17% above what is expected.

For the SPI port (4.69MHz), I set Clock Phase and Polarity both equal to 1.  For the McBPS ports (9.38MHz), I set the transmit and receive clk polarity both equal to 1.

Do you see any problems with the way they are configured?

Stephen

Hello Tom,

Do you have any working code that I can use to verify my setup?

Stephen

Hi Stephen,

For the return values that are about half of what's expected, that could be a reference issue or it could be that you are reading data on the wrong edge and essentially right shifting the conversion results.  For the 14-17% high, not sure what to make of that without seeing how the analog inputs are getting sampled.  It could be timing or reference here as well.  Unfortunately i do not have any code working with this processor at the moment.  I'll look around though.  Can you get some screen shots with an analog scope instead of the USB logic analyser?

Hello Tom,

I am not able to extract the data at this time, but I can describe what it looks like.

The ADS outputs data (after a slight delay) on the falling edge of SCLK and the McBSP transmit pin is outputting data on the rising edge of SCLK.

According to the user's guide for ClockStop =3, CLKRP = 1, CLKXP = 1, the  McBSP receives data on the falling edge. Because of the slight delay in the ADS outputting data, the last bit (the lowest order bit) will be missed.  Is that correct? 

I believe this is what is causing the data to be half of what it is suppose to be. 

The ADS8528 outputs data on the falling edge.  Does it also receive data on the falling edge?

Stephen

Hello Tom,

Here are the Logic Analyzer screen shots you requested.

The first one is probably not of much use since it shows the complete Write/Read of the Configuration Data.

Hopefully the titles are self explanatory.
Stephen

Set and Read Configuration for ADC#3 (Complete Screen Shot):

Set Configuration for ADC#3 (CloseUp of Configuration Data Screen Shot):

Set Configuration for ADC#3 (CloseUp of Configuration Data Screen Shot):

Read ADC#3 Channels (All Channels)

Read ADC#3 Channels (Channel A0)

Read ADC#3 Channels (Channel A0 Closeup)

Hello Tom,

Figure 1 in the ADC's data sheet seem to imply the following:

ADC Outputs data on SCLK's Rising edge, so the McBSP should capture on Falling edge.

ADC Inputs data on SCLK's Falling edge, so the McBSP should output on Rising edge.

However, according to my captures, the ADC outputs data slightly after SCLK's falling edge.  Does the Falling edge of SCLK cause the ADC to output data?

Stephen

Hi Stephen,

I was hoping to see an analog scope capture - can you tell me what the frequency of your SCLK is?  Data into and out of the ADC should be valid on the falling SCLK edge.  The SDO changes after the falling edge with a fixed delay so with a slow SCLK, it can give the impression that it should be considered valid on the rising SCLK edge.

The SCLK is 9.38MHz.  Reducing it significantly (18.76Mhz/256 = 73.28kHz, I checked the clock frequency with an oscilloscope) didn't change the situation.

Stephen

Update: See correction to my previous post below below.

Hello Tom,

The ADC connected to the SPIA port is working ok.

The two ADCs connected to the McBSP ports are 1/2 of the of their expected value.

The two ADCs connected to the SPI port are given reading of 1/2 of the expected value. 

In my test data, I noticed the first couple of sample data (after performing a conversion) for ADC#3 (McBSPb port) contains ADC configuration data.  I remembered the documentation saying something about the configuration data being available after the first two accesses, so I decided to read an extra 32-bits after setting the ADC configuration.  That worked the first time I tried it, but not the second time.  What's also strange is that ADC#3 sometimes (after performing a conversion) only returns the lower 16 bits of the configuration data.  There was also a time it returned 0x4000C1FF, which would cause the reference to be half of its value. However, almost all of the time it returns 0x400083FF.

Any ideas?

Stephen

Hi Stephen,

I'll contact you via your profile e-mail account.