ADIS16465 SPI issue

I've been trying for far too long now to communicate with an ADIS16465, with no success. The Datasheet for the 16465 says to use CPOL = 1, CPHA = 1, which translates to 'clock normally high' and 'sample on rising clock edge'. I send 0x7200 for PROD_ID, then I send a second 16-bit write (0x7200 again, but 0x0000 has the same effect) and I get zero (0x0000) response.

In desperation, I tried every other combination of CPOL and CPHA. The only one that generates a response is Mode 1, CPOL=0 and CPHA=1. Here is the response.

This returns a value of 0x0028 to the microcontroller (PSoC5), which is of course not equal to the actual PROD_ID 0x4051. But the MISO response looks like it's trying to put out 0x..51: see it? It's just shifted to the right a half-cycle!

Here's a closer look at just the second half of that pair:

See how the MISO and MOSI are 90° out of phase, measured with respect to CLK? MOSI is sending a signal that is sampled on a falling clock signal, MISO is sending a signal that is sampled on a rising clock signal. So what is going on? I'm probably missing something obvious, please help!

Oh, and in response to the obvious first questions:

  • Everything is running at 3.3V
  • This signal is completely consistent and repeatable
  • No other combination of CPOL and CPHA give me anything in response
  • f_clock = 500 kHz

Thanks in advance for any assistance!

  • Hello,

    Between issuing a SPI request and reading back the response, you must wait for the SPI stall time. For the ADIS1646x family, the SPI stall time is 16us. Violating the stall time can cause a number of problems - shifted response data, zero response data, etc. Based on your scope shot, it looks like you have approximately 7us of stall time between the transactions.

    Example valid read of register containing 0xA5A5 w/ 16us stall

    Read with an invalid stall (7us) produces shifted response data:

    Hope this helps,

    -Alex Nolan

  • Thanks so much, Alex. This helped -- I was inadventently timing T_stall from the start edge of CS rather than from the end edge. Everything is working now, much obliged!

    The other part of the problem, which further obscured the issue, was that on the PSoC I was using for a controller the MISO pin was getting fanout drop and not reliably being read. Buffering MISO in the definition of the pin on PSoC Creator fixed that issue. (I know this is the ADI zone, but I'm putting it here in case anyone else struggles with getting SPI to work with the combination of Cypress PSoC and ADIS16* sensor.)