Not able to read the Product ID from ADIS16260 Gyroscope Sensor

Thank you for your post and for your investment into using this product in your development. We are on vacation for two more days, but perhaps this blog entry may help in the interim. Can you take a look at this and see if that helps? I was not able to click on the link that you provided yet, but I can do so when I return late this week if you still need help at that time.

https://ez.analog.com/blogs/engineeringmind/2015/02/05/connecting-to-smart-sensors-it-takes-more-than-code

NevadaMark, Thank you for sharing the link. I will read through it and get back if needed.

In the past, I have interfaced several external devices using SPI interface and I totally agree with the points you have made in your blog post, hence I iterated again through my SPI connections and configurations, wiring etc., I have also captured and analyzed the SPI signals but all looks good [You can take a look at the Link I have shared in my question for the image]. After digging a little, I came across another post of yours where you have shared a code snippet for reading the product ID from ADIS16480 here. 

I haven't tried this code snippet yet, as before doing so I went through the code to understand what is being done to read the product ID, as I believe it's a tested and working code. I presume there is a mismatch in my understanding from the datasheet and what's actually being done in the code snippet you have shared.

According to the datasheet here, on page 11, it is said that to perform a read operation, two 16 bit transactions are to be done with a minimum stall time of 9 us. The first 16 bit consists of the register address to read from i.e. 0x5600 and the second 16-bit transaction is to read the product ID information. If we convert this information to code, this is what it will look like:

 /* For full code and details, PL refer to the link I have shared in my question */
Serial.println("Reading Product ID...");      digitalWrite(CS, LOW);      SPI.transfer16(PROD_ID_ADDR);               //PROD_ID_ADDR is 0x5600 & 16 bit Transaction is done      digitalWrite(CS, HIGH);      delayMicroseconds(STALL_TIME_US);           //Stall Time is 10us      digitalWrite(CS, LOW);      get_data = SPI.transfer16(0x00);            //The product ID is read in the next 16 bit Transaction      digitalWrite(CS, HIGH);

Now coming to the code snippet you have shared, things have been done a little differently i.e.

1.   digitalWrite(CS, LOW);
2.   byte msb2=SPI.transfer(highByte(prodid));
3.   byte lsb2=SPI.transfer(lowByte(prodid));
4.   int prod2=msb2*256+lsb2;
5.   Serial.print(prod2);
6.   Serial.println(',');
7.   digitalWrite(CS,HIGH);

In line No. 2, we perform an 8bit transaction during which we send 0x7E on MOSI which is basically the most significant byte and simultaneously read 8 bits from MISO and store it in 'msb2'. In line No.3 again, we do the same as we did in line No. 2. This basically constitutes for a 16-bit transaction during which we get msb2 and lsb2. So my questions are:

1. Isn't the product ID supposed to be read during the next complete 16-bit transaction as per the datasheet?. However, in the above code snippet, there exists only one 16-bit transaction which is done in two segments of 8-bit transactions.

2. Why is it required to perform 2 separate 8-bit transactions to send the address, why not just do a 16-bit transaction passing the argument as 0x7E00?

3. Why is line No. 4 required? and what does it do?

4. I don't see any stall time here?

It would be of great help if you could shed some light on the above questions correlating with my understanding. Thanks.

Sorry, my code looks unformatted, please use this one for your reference or you can view the link I have shared in my question.

Serial.println("Reading Product ID...");
digitalWrite(CS, LOW);
SPI.transfer16(0x5600);
digitalWrite(CS, HIGH);
delayMicroseconds(STALL_TIME_US);
digitalWrite(CS, LOW);
get_data = SPI.transfer16(0x00);
digitalWrite(CS, HIGH);

I looked at your link and didn't see a scope shot of the signals, only logic diagram.  Based on the logic diagram, I would say that your code is generating the expected signals.  What I do not know is:

1. Physical pictures of your setup, which clearly illustrate the ADIS16260, the board it is on, Arduino and everything in between.
2. Is the ADIS16260 turning on? (measuring power supply current or checking for a pulsing signal on DIO1 may help)
3. Have you inspected the integrity of the signals with a scope?  Logic analyzers do not provide insights on spikes, ringing and other sources of error in the signals.

Regarding your point 2, I just want to clarify if we are on the same page--> do you mean that, as soon as I supply 5V power to the ADIS16260, the DIO1 pin starts generating pulsating signal?, If this is the case, then I can probe the DIO1 pin to confirm if the ADIS16260 has been at least powered up. To check the integrity of the signals, unfortunately we do not have a DSO as it is too expensive. However, I can take it for rent, but before suspecting the integrity of the signals, I would like to look into all other aspects and eliminate all other possibilities that may be causing this communication failure.

Actually, now that I review the datasheet. the default state does not provide a data ready on this product (it does on our new products).  sorry about that.

Oh is it, thats fine. Between, I also really doubt if this issue has to do anything with the integrity of the SPI signals, as a month ago I was able to successfully communicate between an ESP8266 and Arduino UNO using the SPI.

As advised, I am sharing the pictures of the device and the hardware setup,

1. Top View of the ADIS16260

2. Bottom View of the ADIS16260

3. Side of the Hardware Setup

4. Top view of the Hardware Setup,

Please let me know if there is anymore information I can share to help you support me in getting this to work. Thanks.

NevadaMark, or anyone in this form can help me with this?

I apologize!!!  I typed this following response, right after your last message and just discovered that it did not post.  Very strange.  Here you go.....

I understand you offering this following statement:

• I also really doubt if this issue has to do anything with the integrity of the SPI signals, as a month ago I was able to successfully communicate between an ESP8266 and Arduino UNO using the SPI.

but.....

I have seen many cases where such assumptions turned out to be untrue, so I would prefer to see signals on a scope, especially with that wiring approach. SPI is not intended to work that way.  I don't care if it worked on another sensor;  this defies several "best engineering practices" for such connections.  This may not be your problem, but it is not as clean as it could be.  In general:

• Keep runs as short as possible.
• If you need to go more than a few inches (2-3), use twisted pairs (one signal, one ground) to minimize inductance, which will  combine with parasitic capacitance to  cause ringing and reflection.
• Inspect your signals on a scope (not a logic analyzer) to make sure you don't have any latent risk from noise, ringing or marginal timing

I would also check the power supply current as well, against the expectation from the ADIS16260's datasheet. 

Next, I would probe for continuity between each pin and both VDD and GND.  If any pins are shorted to unexpected places, perhaps there is damage from the assembly process.