ADS7960: SDO always reads 0

Hi Kaushalya,

1. No. Programing the other modes is not necessary. If you are using the GPIO's as outputs then you may want to look at the GPIO register since the GPIO's are inputs by default. 

2. The commands you are sending should accomplish what you intend. Are you able to provide a scope capture of CS, SCLK, SDI and SDO? Additionally, are you using an EVM or a custom board? If using a custom board, can you provide a schematic so that I may take a look? 

If you are reading all 0's on SDO, then I would believe that there is a strong possibility of a communication error. 

Regards,
Aaron Estrada

Hi Aaron,

Many thanks for your reply. 

1. Yes thats what I thought as well.

2. I have attached a scope capture for the initialization sequence. At the end of this, I should see the GPIO0 going high, but it is low. So that means the comms failure I guess. In the scope capture, ch3 is MOSI, ch4 is MISO.

 init.csv

I am using a custom board. The schematics also included.

NTC.pdf

Please let me know if you can see anything not right here. 

Cheers,

Kaushalya

Hi Aaron,

This is a complete read cycle.

This is the 3rd frame of the complete read cycle.

Hi Kaushalya,

I don't see anything that stands out that would be causing an issue. Where are the SPI signals going to? Do you have an MCU on the board? It looks like you are sending 0x1801 first but would configure the GPIO register before putting the device in manual mode. So I would send commands in the order:

0x4001

0x1800

0x1D01

The GPIO should toggle right after it is told to. So you should see GPIO0 go HIGH after sending 0x1D01. I have confirmed this on my end. However, I am still getting activity on SDO. This is expected because we are still acquiring and converting the channels. Can you share details on what sample rate you wish to use? What is the SCLK frequency? Have you checked the supplies with a DMM to ensure they are at the appropriate level? Can you probe the AINP pin (Output of OPAMP) just to make sure you are getting an expected value?

Regards,
Aaron Estrada

Hi Aaron,

I tried your sequence but unfortunately the GPIO0 is still low and no SDO from the ADC.

The delay between CS going low to the first rising edge of clock shouldn't matter as far as I see from section 7.9 and Figure 4. Am I correct? For SDI (MOSI) the important timing parameters are td1, tsu2,th2 and tq, am I correct? 

I am not looking for any particular sample rate at this time, but it would be really slow like 10-30 seconds. Yes the supply I have checked. It is solid at 3.3V across the bypass caps. I couldn't check right on the pins as  I use a VQFN package. 

The SCLK frequency is 750kHz.

The voltage at at AINP is 0V. The CH10 input is at 1.7V, Vref 2.48V. So looks like the mux has not operated as well.

Cheers,

Kaushalya

The ADS7960 is interfaced to the processor via a shared SPI bus. However I have isolated all MISO lines from other slaves so that they dont interfere with SDO of ADS7960. Still no luck.

I have also attached the processor page of the schematic.

Processor.pdf

Cheers,

Kaushalya

Hi AAron,

I also noticed the following in the SDI signal. The data being transmitted is 0x4001. 

But there are two abnormal pulses, which comes very close to the VIL max limit (400mV). It is way low to be registered as a high, but kinda very close to the gray area of logic. What do you think? 

Cheers,

Kaushalya

Hi Kaushalya,

Your understanding on CS going low to SCLK rising edge is correct. There is only a min spec for this. As for the other timings, yes, these are the ones you should double check. Just eyeballing it, they look to be fine. The CS high time also has a minimum spec but it looks like you are sending a CS high pulse of ~2.5us so that should be well within the spec. 

Can't believe I missed those additional pulses from your original scope captures. They definitely look fairly clean and as if something else is trying to pull the line high. It should be within the Vol spec but I agree this is pretty close to that gray area. After isolating the MOSI lines, did you still see the pulses?

As for the AINP measurement, is the 0ohm resistor currently populated? I would also recommend measuring the MXO pin if you haven't done so already. I had forgotten there was an opamp between the two pins and the 0ohm resistor. Either way, this should not prevent the device from setting a GPIO status. 

Regards,
Aaron Estrada

After looking into the schematic bit more carefully, after seeing that 'ghost signal' on MOSI, it occurred to me my stupid mistake. The MOSI and MISO are connected vice versa!!!

After I fix it for ADC, I can now see the ADC spitting out some data, but still no GPIO0. But I am one step closer now.

GPIO0 is turned on after I read a channel by sending 0x1801 three times.

Also I can manually read the channels the same way.

Could you please confirm that after 0x4001, 0x1800 and 0x1d01, the GPIO0 was HIGH?

Thanks,

Kaushalya

Hi Kaushalya,

Glad to see you found that mistake. That is something I should have caught too... MISO and MOSI still confuse my just by looking at the lettering...

Writing 0x4001 sets GPIO as an output. 0x1800 access the manual mode register but also sets the GPIOs that are configured as an output to a LOW status. 0x1D01 access the manual mode register and sets the channel to be read to CH10 as well as sets GPIO0 to HIGH. This should toggle the GPIO pin. I have included some pictures of a similar pattern below. On the EVM I used, GPIOs are pulled high and I did not have access to GPIO0 so GPIO1 was used. 

I used an SPI host controller with an EVM and captured some images shown below. The signals in order from top to bottom are CS, SCLK, SDI, SDO and GPIO1. I first sent command 0x4002 to set GPIO1 as an output. You can see the GPIO1 pin go LOW. This is due to the manual mode register setting all GPIOs to LOW by default. Next, 0x1802 was sent to toggle GPIO1 HIGH. Finally, I toggled GPIO1 back low by sending 0x1800. 

The commands you are sending follow a similar structure and you should be seeing GPIO0 toggle. 

Kaushalya Satharasinghe said:

GPIO0 is turned on after I read a channel by sending 0x1801 three times.

Were you actually able to toggle GPIO0 or is this statement saying that it should toggle?

Regards,

Aaron Estrada