8451 I2C Loop Running Slowly When Reading Data

[Nick-C]

I believe that both of us are struggling to properly understand this data sheet. It is not explained clearly whether or not for SPI you are to be writing MSB first or LSB first. 

However it seems like we've tried all the options, we know that the device is malfunctioning and unless you've made changes in the 845x library VIs there shouldn't be anything wrong with the LabVIEW code. Does the manufacturer of this device have a support line you can call? In the past I've found application engineers at the manufacturer to be very helpful in understanding device specifications.

I'll continue trying to see if I can dig up any additional information or ideas on why we are unable to communicate. It's strange that I2C works with no problems but we cannot get SPI communication working. 

-Nick-

[lgbav8r]

I have been in contact with an applications engineer at ST prior to turning to the labview forums.  He provided some help but now seems unwilling to continue to help diagnose the issue.  I sent him the same MOSI and MISO oscope images I posted here.  I will continue to seek a resolution to this issue.  I am convinced that it is me doing something wrong since 2 sample from different sources experience identical symptoms.

Just for clarification I have not modified any 845x VIs and I am using the lastest version of them (2.1).

[Nick-C]

I read through the SPI section of the datasheet again this morning and based on that information and the information you have provided, I cannot find any inconsistencies that would cause the device not to return data. We know your 8451 is operating properly and the sensors are functional becaues they operate using I2C. 

The documentation regarding SPI seems abiguous in places and the manufacturer should be able/willing to help clear that up. Let us know if you make any headway and I'll continue to try and find a solution.

-Nick-

[lgbav8r · Accepted solution]

I have found the solution to the SPI issue!

For some reason, I cannot send 0x00 as my dummy data when using SPI reading.  However, if I send 0xFF as dummy data, reading is accomplished.  I am able to get the correct device ID and read all acceleration data.

An ST application engineer has confirmed that he was able to send 0x00 as dummy data and still recieve the correct values using his SPI master (not an NI product).  He has suggested that it might have something to do with the SPI master (USB-8451).

I'm not sure why this is happening but I know how to resolve it an move forward.

Additionally, I am able to obtain a 1300 Hz sampling rate now using SPI using maximum clock speed which is still significantly less than the 5000 Hz desired.  I believe the limitiation is a result of the overhead in 8451 resulting in a pause between each byte on the clock (This is documented in the 8451 manual).  I have an 8452 on order which should get around this by offering streaming mode.

[Branch_Support-NIC]

Glad to hear the manufacturer was able to help you sort out the problem. You are correct that the 8451 introduces a 10-20 uS delay between multi-byte writes. This knowledge base article and the manual you reference mention that. Best of luck with the application, if you have any other questions come up, post back.

-Nick-