Questions about SPI

[sheershak-agarwal]

Hello,

Situation:
I was working with SPI on F' to connect to my IMU. (I need to run on mode 3 and rx tx bit length is 16, which is quite unusual.)

I have to send one 16 bits command and receive seven 16 bit values. Since RPI doesn't support bit length of 16, so I am sending two eight bits command and receiving fourteen 8 bits values. I understand that there will be 1.5 microsecond delay between the two eight bits and that's what I am trying test with the IMU is good for us.

My problem:
So I am using this code which I took from the RPI example, I can see the clock for the send bytes but not the receive bytes. Please see the diagram attached. So I looked at the SPI driver and in readwrite function

fprime/Drv/LinuxSpiDriver/LinuxSpiDriverComponentImpl.cpp

Line 51 in 37b4bfe

tr.len = writeBuffer.getSize();

, we were just adding length of write buffer.

char inBuf[14];
Fw::Buffer in;
in.setData((U8*)inBuf);
in.setSize(sizeof(inBuf));

char buf[2] = {0x3E, 0x00};
Fw::Buffer out;
out.setData((U8*)buf);
out.setSize(sizeof(buf));
this->SpiReadWrite_out(0,out,in);
printf("IMU bytes\n");
for (int i = 0; i < 14; i++) {
  printf("%x ", inBuf[i]);
}
printf("\n");

So I changed my code to make the write buffer length = write + read length (2+14). and then my data looked a lot better but when I print the bytes on f', they are different from what it is on the image attached.

char inBuf[14];
Fw::Buffer in;
in.setData((U8*)inBuf);
in.setSize(sizeof(inBuf));

char buf[16] = {0x00};
buf[0] = 0x3E;
Fw::Buffer out;
out.setData((U8*)buf);
out.setSize(sizeof(buf));
this->SpiReadWrite_out(0,out,in);
printf("IMU bytes\n");
for (int i = 0; i < 16; i++) {
   printf("%x ", inBuf[i]);
}

The data I am getting on terminal in this scenario is:
IMU bytes
7f ff 80 8 bf fb bf ea 80 b 80 1 bc 15 bf d0

[LeStarch]

My understanding with SPI is that you read and write at the same time. Thus even if you are only required to write 16 bits, you still need to provide a buffer that is 16bits + 7*16bits long.

What happens if you try this:

char inBuf[2 + 14]; // in and out buffers should be the same size
Fw::Buffer in;
in.setData((U8*)inBuf);
in.setSize(sizeof(inBuf));

char buf[2 + 14] = { 0 };
buf[0] = 0x3E;
buf[1] = 0x00;

Fw::Buffer out;
out.setData((U8*)buf);
out.setSize(sizeof(buf));
this->SpiReadWrite_out(0,out,in);
printf("IMU bytes\n");
for (int i = 0; i < 16; i++) {
  printf("%x ", inBuf[i]);  // bytes likely in position 2 - 15, as device needs 16bit command before responding.
}
printf("\n");

[LeStarch]

The first two bytes are device dependent. It will usually say what they should be in the datasheet. Sometimes the device is fast and can respond with the real data. Sometimes it will be ack bytes. Sometimes garbage.

[sheershak-agarwal]

yes, i will add that data in a minute. thanks again for the clarification

[sheershak-agarwal]

added please check the description

[LeStarch]

Can you rule out noise and/or wiring issues between the device and the CPU? Do you see the data you expect (known bytes/words) on the diagram or in the printed bytes? Your code seems ok to me...and so I might look for a hardware cause. Also ensure this:

char inBuf[14];

Is really this:

char inBuf[16];

I am assuming that it did not get updated in the description.

[sheershak-agarwal]

There is nothing other than IMU connected to my rpi and all the hardware connections are good. I don't know if either of those are the right packets. I will cross check with other MCU where I know the data is right. Yeah I didn't update the inBuf to 16 in the description but my code has that change.