• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 46 subscribers
  • Views 3222 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.

ADS124S06: SPI communication problem

Alexander Foken
Prodigy 20 points

Part Number: ADS124S06
Other Parts Discussed in Thread: ADS124S08EVM

Hi!

We have a ADS124S06 connected to an Atmel SAMD21, using 47 ohms in-line resistors for all data lines as recommended in the datasheet (figure 111) except for -DRDY (pin 13). START/SYNC (pin 8) and CLK (pin 17) are tied to DGND. The ADS124S06 is mounted on a custom test board, the SAMD21 is on a Sparkfun breakout board, connection between boards is done via short jumper wires, as usual for our test setups.

AVCC is connected to +2.5V, AVSS and AVSS-SW to -2.5V, IOVDD and DVDD to +3.3V.

My SAMD21 software sends a reset pulse to pin 18, waits 2 msec, then starts by reading all 18 registers, sending out 0x20, 0x11, followed by 18 bytes of 0x00. I expect to read back two bytes of junk, followed by the default register values (0x00, 0x80, 0x01, 0x00, 0x14, 0x10, 0x00, 0xFF, ...). I get back 20 bytes of 0x00. SPI clock was about 1 MHz, reducing the SPI clock to about 100 kHz did not help at all.

I've verified that the SAMD21 SPI interface is ok. The ADS124S06 is actively forcing MISO low. SPI signals look ok on a scope. The ADS124S06 sends pulses on the -DRDY line (pin 13), so my SAMD21 software attempts to read back samples using the RDATA command (0x12) followed by 0x00 bytes. It reads back a stream of 0x00. We have double checked and triple checked the layout, the soldering, possible shorts etc., so it is not caused by a trivial hardware fault.

To rule out any software issues, we've bought an ADS124S08EVM eval board, populated the J3 header, and tested simply reading the register values using the TI PC software. The bare board reads back the registers as expected. Attempting to measure the SPI signals CS and SCLK with 1:1 probes on a scope (1 MOhm || 13 pF) caused the PC software to read all registers back as 0x00, like in our test setup. Switching SCLK to a 10:1 probe caused random switches between expected values and 0x00. Switching also the CS probe to 10:1 gave stable values. Connecting two more 10:1 probes to MISO and MOSI allowed us to watch the register read-out working as expected on the ADS124S08EVM. The exact same sequence of 0x20, 0x11, and 18 times 0x00 was send out, and after two junk bytes, the register default values were read back.

Our test board usually does NOT have a scope connected, but still it only returns 0x00.

So:

Why does the ADS124S06 on our test board constantly return 0x00?

Why does the ADS124S08EVM show the same behaviour when probing the SPI lines with a 1:1 probe (1 MOhm || 13 pF)?

Does the ADS124S0x need some extra hardware to be able to communicate with the SPI interface of a generic 3.3V microcontroller?

Thanks in advance.

  • 0
    TI__Guru** 113765 points
    Hi Alexander,

    Welcome to the E2E forum! It is usually not difficult to communicate to the ADS124S06/08. In the case of the EVM, there are bidirectional level shifters that are designed in such a way that there is a pullup internal to the level shifter. A cap load with lower impedance will cause an issue both with timing and the creation of a voltage divider where the load may cause the Vih and Vil for the digital inputs to be out of a valid range. It is always a good idea to use the probes at 10:1.

    As to why your setup isn't working is difficult to say. If you have scope/logic analyzer shots of the communication that you can post that would be helpful. One of the biggest mistakes that are made with the SPI communication is with respect to framing. The entire communication transaction requires CS to be low throughout. If CS toggles at any point the communication stops. The best method is to use GPIO to toggle CS as the frame size will vary from command to command. Make sure that the required time for CS low to first rising edge of SCLK is correct. Also make sure that the SPI communication is Mode 1 (clock dwells low on idle, and data changes on rising edge and stable on falling edge).

    I would also verify that the startup delay following RESET is as you would expect. Also verify that your supplies are present at the ADS124S06 input pins. For example, if AVDD/AVSS are not applied, the device will be held in reset until all supplies are valid. You should also connect your analog supply common to digital ground (AGND=DGND).

    Based on your comment that DRDY is toggling, it would appear that the device is operating. However, this is a condition that I would not expect as the device following reset will be in a standby state and requires either the START pin to go high, or the START command to be issued. If START is low, then I would not expect DRDY to be toggling unless the command has been issued.

    Best regards,
    Bob B
  • 0 in reply to Bob Benjamin
    Prodigy 20 points

    Hi,

    SPI issues are solved. Several bugs in an untested part of the SPI driver caused wrong data on the MOSI line and framing errors. Also, RESET and DREADY were at some point in time rewired to the wrong pins.

    1:1 probe issue seems to be limited to the ADS124S08EVM, our test setup based on our own board acepts 1:1 probes at 1 MHz SPI clock.

    Thanks,

    Alexander