ADIS16467 SPI communication issue

Hello,

I have a problem with communication with ADIS16467.

I have experiance with ADIS16334 and ADIS16362.

This time, using the same embedded system like for two previously used ADIS, I am not able to read PROD_ID.

My SPI configuration is similar to configuration I use for 16334 and 16362 except Tcs and Tstall.

No matter what register address I read, only 8 upper bits are  send back. For instance, if I read 0x7200 I receive 0x40 (PROD_ID for 16467 is 0x4053 == 0100 0000 0101 0011)

or if I read Z_ACCL_OUT (0x1A00) I receive 0x0003 while I should receive more less 000 0011 0010 0000  (ADIS is level so the output should be ~800LSB * 1.25 == 1000mg).

I have noticed that If I do one additional 16-bit cycles on SPI the 8 lower bits are received (accoriding to the specification: "reading a single register requires two 16-bit cycles on the SPI").

I checked all ADIS signals and they looks OK on the scope. Bellow are some screenshots.

I checked power supply current and it is as specification says.

One more thing, I also noticed that if I add some delay in the code (like 800 of asm"nop") just after new 16bits value is put into SPI TX register (this line starts sendind data to ADIS), I am receiving correct data. However such delay should not be in the C code. The same effect I obtained replacing "nops" with putting a breakpoint in the same line where nops were (so I also put some delay because to do second 16-bit cycles on SPI I have to release the breakpoint).

CS

SCLK

DIN - 0x1A00 (0001 1010 0000 0000)

DOUT = 0x0003

and some another screenshots

DR

CS

and

some screenshots with two signals

DR + CS (CS starts on the second edge of DR)

CS + SCLK (tcs= ~800ns)

I am wondering what else I missed.

Parents
  • Found the same issue this last week. The problem i'm noticing (which obviously isn't the proper behavior in the data sheet) is that the samples of return data come 16 bits after when they should. What I mean is that I'm getting the correct data, but I have to pass the unit one more dummy read before I get the second byte of data from it. This is obviously not the behavior that is expected.

    For example, a typical read of the 0x7200 you need to give it two more dummy bytes to get the answer back (supposed to be 0x4053). However, the behavior you are seeing is that you are getting a 0x0040 correct? Then one more dummy byte gives you back the lower byte (0x53). I modified my code to just add another dummy 16 bits on a staggered read of multiple registers, and it seemed to sort of work, but some of the data that comes back is incorrect from some of the registers.

    There must be some sort of internal software issue that analog devices needs to correct.

Reply
  • Found the same issue this last week. The problem i'm noticing (which obviously isn't the proper behavior in the data sheet) is that the samples of return data come 16 bits after when they should. What I mean is that I'm getting the correct data, but I have to pass the unit one more dummy read before I get the second byte of data from it. This is obviously not the behavior that is expected.

    For example, a typical read of the 0x7200 you need to give it two more dummy bytes to get the answer back (supposed to be 0x4053). However, the behavior you are seeing is that you are getting a 0x0040 correct? Then one more dummy byte gives you back the lower byte (0x53). I modified my code to just add another dummy 16 bits on a staggered read of multiple registers, and it seemed to sort of work, but some of the data that comes back is incorrect from some of the registers.

    There must be some sort of internal software issue that analog devices needs to correct.

Children
No Data