SPI Chip Select Issue

[nathand]

---

@Ben wrote:

... or the Example you have started with fails to set the I/O direction when switching form read to write. If the output is tri-state ...

---

One of the advantages to SPI is that none of the lines need to be tri-stated. The master drives three lines - chip select, clock, and MOSI (Master Out, Slave In). The slave drives one line - MISO (Master In, Slave Out). Each clock cycle, both the master and slave transmit one bit on their output line, and read one bit on their input line. Since the lines are in dedicated directions, there's no switch from read to write.

[Ather.Iq]

I also want to know that how the FPGA code is using the SPI_CPOL and SPI_CPHA because for the gyro it needs to be CPOL=1 and CPHA=1 is the code correct one to be interfaced?

[nathand]

---

@Ather.Iq wrote:

I also want to know that how the FPGA code is using the SPI_CPOL and SPI_CPHA because for the gyro it needs to be CPOL=1 and CPHA=1 is the code correct one to be interfaced?

---

I'm sorry, I have no idea what you're asking here. You can set the mode for CPOL and CPHA to whatever you need. If the FPGA interface provides only a single mode, instead of separate controls for CPOL and CPHA, then you can look up the corresponding mode from an internet search for "SPI modes."

[Ather.Iq]

The Gyro L3G4200D which I am interfacing uses SPI mode 3, I am using the same configuration and CS as low so that communication starts. In the beginning I just want to read the correct address.

The address header byte is as follows:
- - - - - - - - - - - - - - - - - - - - - - - - - - -
_
[R/W] [B] [A5] [A4] [A3] [A2] [A1] [A0] <---- Address header
- - - - - - - - - - - - - - - - - - - - - - - - - - -
_
Which is why I'm sending a 0x80 ORed with 0x0F (WHO_AM_I) to read the register which tells the device ID.

The thing is that as a result the READ Data I am getting is 0x80 ORed with 0x0F but it should return 0xD3.

I have tried every thing but the data I am not getting correct.

Kindly advice me where I am wrong or have done any mistake.

The snapshot of VI block diagram "SPI"is attached for reference

Regards,

[nathand]

Again, I'd try the other SPI implementation I mentioned in an earlier post.

Have you connected an oscilloscope to check the actual signals? Can you confirm that the device is in fact driving the MISO (or SDO) pin?

When you mention the data that you read back: the SPI VIs are actually returning 2 bytes, since every clock cycle on the SPI bus is one bit transferred in each direction. However the read data that you said you're getting is only 1 byte. What's in the second byte?

[Ather.Iq]

I have checked the signals by connecting an oscilloscope, The data getting on MISO pin is attached.

The SCLK, MOSI waveforms are also attached.

The SCLK is when the Data Read is 8F in the First Byte while 2nd Byte is 0x00, Idon't know where I am wrong kindly correct me.

[nathand]

Try putting SCLK on one scope channel and MISO on the other. Send one command to the device (ie, don't put a loop around your code), and capture the entire exchange. You can then manually check that the data you read in your LabVIEW application matches what was actually sent. Is this an option for you?

[Ather.Iq]

The SPI document which I have read says to Write the data, CS must be LOW and then the 8 bits commands of the register address + 0x00 (another 8 bit) completing 16 bit data to be put on MOSI line. Then CS must be assreted HIGH so that data can be read on MISO line. But in my case, I am getting the same data which i've written and read same in the READ data buffer in the SPI_SINGLE_PORT Example. The question is that do I need to make CS High in the code which I have used.

[nathand]

---

@Ather.Iq wrote:
Then CS must be assreted HIGH so that data can be read on MISO line.

---

No, that's not how SPI works. CS must be low for the entire length of the data exchange, as shown in the timing diagram. A slave SPI device must not drive the MISO line if CS is not active. While CS is active (low, in this case), for each bit that you write you also read one bit. Here, you write an address in the first byte, and read back the data at that address in the second byte (while you're sending the 0x00). You should ignore the data in the first byte that you read, and look for the desired data in the second byte.

If you have access to an oscilloscope with 4 input channels, it would help a lot to probe all 4 lines simultaneously and capture one full data exchange, from the moment CS goes low, to the moment where it goes high again. If you only have 2 channels on your scope, do 2 channels at a time. You should see the address that you send, and the data that comes back.