Linux/ADS7953EVM-PDK: Unable to read ADC output both in One-shot Mode and Continuous Mode

No, I don't have any other SPI working. I've checked the device tree and seems fine.

Yesterday I have noticed a strange error immediatly after the probe of the driver:

ti_ads7950_probe
/soc/aips-bus@02000000/spba-bus@02000000/ecspi@02008000/adc@0: could not find phandle

What does it mean? Why the pointer to the adc node can't be found?

Regards,

Fabio

Hi Vishy,

the problem was caused by a wrong description of the ADC in the device tree. See the following binding:

* Texas Instruments ADS7950 family of A/DC chips

Required properties:
 - compatible: Must be one of "ti,ads7950", "ti,ads7951", "ti,ads7952",
   "ti,ads7953", "ti,ads7954", "ti,ads7955", "ti,ads7956", "ti,ads7957",
   "ti,ads7958", "ti,ads7959", "ti,ads7960", or "ti,ads7961"
 - reg: SPI chip select number for the device
 - #io-channel-cells: Must be 1 as per ../iio-bindings.txt
 - vref-supply: phandle to a regulator node that supplies the 2.5V or 5V
   reference voltage

Recommended properties:
 - spi-max-frequency: Definition as per
		Documentation/devicetree/bindings/spi/spi-bus.txt

Example:
adc@0 {
	compatible = "ti,ads7957";
	reg = <0>;
	#io-channel-cells = <1>;
	vref-supply = <&refin_supply>;
	spi-max-frequency = <10000000>;
};

Since the vref is generated by the ADS7953EVM-PDK and not by the i.MX6 EVB there is no need of a "refin_supply". So I have created  a dummy regulator and specified it in that field. The phandle error has disappeared.

I made futher steps in the debug. As of now I see the CS, CLK and MOSI signals moving correctly but the MISO is still unresponsive. I can't get any output from the ADC. I hope to come back soon with a solution

--

Fabio

Hi Vishy,

I know the ADS7953 has a 2 cycle delay on start-up. That's how the driver behaves:

/*
 * Setup default message. The sample is read at the end of the first
 * transfer, then it takes one full cycle to convert the sample and one
 * more cycle to send the value. The conversion process is driven by
 * the SPI clock, which is why we have 3 transfers. The middle one is
 * just dummy data sent while the chip is converting the sample that
 * was read at the end of the first transfer.
 */
st->scan_single_xfer[0].tx_buf = &st->tx_buf[0];
st->scan_single_xfer[0].len = 2;
st->scan_single_xfer[0].cs_change = 1;

st->scan_single_xfer[1].tx_buf = &st->tx_buf[0];
st->scan_single_xfer[1].len = 2;
st->scan_single_xfer[1].cs_change = 1;

st->scan_single_xfer[2].rx_buf = &st->rx_buf[0];
st->scan_single_xfer[2].len = 2;

spi_message_init_with_transfers(&st->scan_single_msg, st->scan_single_xfer, 3);

When I execute a raw read, e.g.:

cat /sys/bus/iio/devices/iio\:device0/in_voltage0_raw

I see on the MOSI the exchages of three 16bit words. The first burst is the following:

0001 1 0000 1 0 0 0000 = 0x1840

that means:

DI15-12: 0001 = Selects manual mode

DI11: 1 = Enables programming of bits DI06 through DI00

DI10-07: 0000 = channel-0

DI06: 1 = Selects 5-V input range

DI05: 0 = Device normal operation (no power down)

DI04: 0 = The SDO pin outputs the current channel address of the channel on bits DO15 through DO12 followed by a 12-bit conversion result on bits DO11 through DI00

DI03-00: 0000 = The GPIO data for the channels configured as an output

The second burst is the same, the driver sends out again the same payload.

The third burst is composed by all zeros, the driver expects the result of the conversion operation from the MISO.

See the following images:

That's an overview of the raw read, in yellow the clock, in blue the MOSI:

below a zoom on the first burst, the 0x1840 word:

then the zoom of the second burst, again the 0x1840 word:

finally the third word, all zeros (that's when I expect the conversion result from the MISO):

Questions:

- Is the driver behaviour correct? Is it ok to send twice the same 16bit word (0x1840)?

- After the device power up I don't do any configuration, do I need to configure something to work in manual mode? Can I directly send out the 0x1840 word to read from channel-0?

Thanks in advance for your time

Regards,

Fabio

Hi Vishy,

thanks for the confirmations.

I have still the following doubts:

- the level of my MOSI signal is idle high, your MOSI is idle low. Is it ok?

- can you confirm that the SPI mode to be used with the ADS7953 is the SPI_MODE_0 (CPOL=0, CPHA=0)?

- I don't understand the description of the bit DI11, in the datasheet I read:

1 -> Enables programming of bits DI06 through DI00

0 -> Device retains values of bits DI06 through DI00 from the previous frame

What happens if I set DI11 to 1? Is the value of DI06 ignored on behalf of the value of DI0 (GPIO0)?

Since I would like to specify the value of DI06 manually (I'm interested about the 5-V input range -> DI06 = 1), which value do I have to specify for DI11?

Thanks and regards,

Fabio

Ahhh, ok, I have badly interpreted the datasheet. Thanks for the clear explanation.

Yesterday I tried to follow with a multimeter the power supplies. In detail I tried to check VCC_D on J2. I have no jumper installed so J2 is not connected to ground, I expect a 5V but I've got less then 1V. It seems like if the ADS7953 is pulling down the voltage (GPIO2, GPIO3 inputs). I have asked to the hardware guys to check if the component is broken or not.

I'll keep yuo updated, again many thanks for your help

Regards,

Fabio