SPI input is always 0 with BeagleBoneBlack Anstrom images

PS: It is mentioned above, that the SCLK must be set as input. Is 0x33 the correct value for it?

I’m not sure about the input, but I know that the clock output is working, as I have successfully sent data to an external SPI slave. I’ll put a wire between MSIO and MOSI when I get a chance and check that the input works correctly.

Seems, like I didn’t state my problem correctly: I have SPI1 working and I can send data without any problems, but when I try to receive data the input i get is always 0, although the signal at the wire is non-zero (same goes for SPI0).

I just got a pretty obvious idea: Input is read at d0, right? I don’t want to test it by wiring 2 outputs (d1, DAC-output) and end with one (or both) broken.

Apologies if this belongs in a separate thread, but I am also having trouble reading on SPI1.

I am interfacing a BBB to two off-axis absolute angle encoders:
http://www.rls.si/en/aksim-off-axis-rotary-absolute-encoder--17584

I have the “Simple SPI slave” version that just sends a 16 bit position code over the SPI bus. I have verified with a scope that CLK and CS signals from the BBB are valid, and that the sensor is transmitting the correct data on the MISO/SPI1_D0 pin.

The behavior I get is that for each encoder value I get some sort of repeating pattern. Each time I move the encoder what I read on the BBB switches to a new pattern. Here are some example patterns:

0xFFFF 1111111111111111
0xFFFF 1111111111111111
0xFFFF 1111111111111111

0x5555 0101010101010101
0x5555 0101010101010101
0x5555 0101010101010101
0x5555 0101010101010101

0x7FDF 0111111111011111
0xFF7F 1111111101111111
0xFDFF 1111110111111111
0xF7FD 1111011111111101
0xDFF5 1101111111110101
0x7FD7 0111111111010111
0xFF5D 1111111101011101
0xFD75 1111110101110101
0xF5D7 1111010111010111
0xD75D 1101011101011101
0x5D77 0101110101110111
0x75DF 0111010111011111
0xD77D 1101011101111101
0x5DF5 0101110111110101
0x77D5 0111011111010101
0xDF55 1101111101010101
0x7D57 0111110101010111
0xF55F 1111010101011111
0xD57F 1101010101111111
0x55FF 0101010111111111
0x57FF 0101011111111111
0x5FFD 0101111111111101
0x7FF7 0111111111110111
0xFFDF 1111111111011111
0xFF7D 1111111101111101

0xFFFD 1111111111111101
0xFFF7 1111111111110111
0xFFDF 1111111111011111
0xFF7F 1111111101111111
0xFDFF 1111110111111111
0xF7FF 1111011111111111
0xDFFF 1101111111111111
0x7FFF 0111111111111111
0xFFFF 1111111111111111
0xFFFF 1111111111111111
0xFFFF 1111111111111111
0xFFFF 1111111111111111
0xFFFF 1111111111111111
0xFFFF 1111111111111111
0xFFFF 1111111111111111
0xFFFF 1111111111111111
0xFFFF 1111111111111111
0xFFFF 1111111111111111
0xFFFF 1111111111111111
0xFFFF 1111111111111111
0xFFFF 1111111111111111
0xFFFF 1111111111111111
0xFFFD 1111111111111101
0xFFF7 1111111111110111
0xFFDD 1111111111011101
0xFF77 1111111101110111
0xFDDF 1111110111011111
0xF77F 1111011101111111
0xDDFF 1101110111111111
0x77FF 0111011111111111
0xDFFF 1101111111111111
0x7FFF 0111111111111111
0xFFFF 1111111111111111
0xFFFF 1111111111111111

Another symptom is that I am getting a compiler warning that I don’t understand on the line where I am setting the pointer to the read buffer:
spi_status.c:51:22: warning: assignment makes integer from pointer without a cast [enabled by default]

I find it absolutely baffling that the struct is expecting for the rx_buf field a 64 bit integer instead of a 32 bit pointer.

This is how I am setting up my ioctl:

#define RESPONSE_TYPE uint16_t
struct spi_ioc_transfer tr_azimuth;
memset(&tr_azimuth, 0, sizeof(tr_azimuth));
tr_azimuth.rx_buf = &rsp_azimuth; // Throws warning
tr_azimuth.tx_buf = 0; // NULL pointer is OK
tr_azimuth.len = sizeof(RESPONSE_TYPE); // in bytes
tr_azimuth.delay_usecs = 100;
tr_azimuth.speed_hz = 100000;
tr_azimuth.bits_per_word = sizeof(RESPONSE_TYPE)*8;
tr_azimuth.cs_change = 1;
int ret_azimuth = ioctl(fd_azimuth, SPI_IOC_MESSAGE(1), &tr_azimuth);

Relevant things I have tried:

  • I tried both with and without “spi-cpha”, although it should be on according to the data sheet; the slave changes MISO state on rising clock edge.
  • I tried both with the CLK pin set as input/pullup and output/pullup
  • I tried two beaglebones; same behavior
  • A bunch of values for the struct for the ioctl call (In addition to the ones I think are correct)
  • Making ioctl an array of structs of size 1 instead

Does anyone have any ideas? I have tried everything I can think of, and may just start bit banging instead of using the linux API…