Spidev issues

Added by Fred Frantz almost 9 years ago

The dev kit baseboard file has been modified to include a "spidev" device, and the kernel was compiled to include the SPI device driver for users. However, the expected /dev/spidev0.1 file is not generated. Can a pinmux conflict with other devices cause this problem? A possibly related problem is that ECC errors are preventing the kernel from booting from NAND, but it works from RAM.

baseboard-mityarm335x-frantec-aec.c (15.4 KB) baseboard-mityarm335x-frantec-aec.c

Replies (32)

RE: Spidev issues - Added by Fred Frantz almost 9 years ago

Correction in above code
fd = open(devname, O_RDWR|O_SYNC);
should be
fd = open(devname, O_RDWR);

RE: Spidev issues - Added by Jonathan Cormier almost 9 years ago

I believe you want a single IOCTL. See the attached source code duplex method.

Example usage

      tcSPIDevice spi("/dev/spidev1.1");
      struct tsSPIConfiguration spi_conf = {};
      spi_conf.mnMode = SPI_MODE_3; // SPI transfer mode including polarity and clock phase.
      spi_conf.mnLsbType = 0; // LSB first/last.
      spi_conf.mnBits = 8;   // The number of bits per word.
      spi_conf.mnSpeed = 100000;   // The speed in Hz.

      spi.setConfiguration(spi_conf);

Download all files

spidevice.cpp (3.01 KB) spidevice.cpp
spidevice.h (1.79 KB) spidevice.h

RE: Spidev issues - Added by Fred Frantz almost 9 years ago

A single IOCTL call with len=4 returns 4 bytes of 0 value instead of 2 with no difference in the SPI signals.

RE: Spidev issues - Added by Jonathan Cormier almost 9 years ago

Fred, I'm not sure what is wrong. Perhaps if you sent us your schematic someone could look it over.

I'm pretty sure the spidev driver works. However you could try implementing a simple kernel driver to access the spi calls directly. Or you can try accessing the spi device from u-boot. Though verify that spi0 is pinmuxed in u-boot first.

U-Boot# help sspi
sspi - SPI utility command

Usage:
sspi [<bus>:]<cs>[.<mode>] <bit_len> <dout> - Send and receive bits
<bus>     - Identifies the SPI bus
<cs>      - Identifies the chip select
<mode>    - Identifies the SPI mode to use
<bit_len> - Number of bits to send (base 10)
<dout>    - Hexadecimal string that gets sent

If you wanted to verify that the spi0 MISO is properly connected to the processors spi0_d1. You could pinmux the pin as a gpio and drive it high/low and check for it on the scope.

static struct pinmux_config __initdata spi0_pin_mux[] = {

        {"spi0_cs0.spi0_cs0", AM33XX_PIN_OUTPUT_PULLUP},
        {"spi0_cs1.spi0_cs1", AM33XX_PIN_OUTPUT_PULLUP},
        {"spi0_sclk.spi0_sclk", AM33XX_PIN_OUTPUT_PULLUP},
        {"spi0_d0.gpio0_3", AM33XX_PIN_OUTPUT},
        {"spi0_d1.gpio0_4", AM33XX_PIN_OUTPUT},
        {NULL, 0},

}

RE: Spidev issues - Added by Lukas Aldrich over 6 years ago

I know this is an old thread, but I came across this issue recently. In order to get any MISO data returned, the clock needs to be defined as an input. See AM437x spidev issue - no MISO data where the TI engineer explains this.

RE: Spidev issues - Added by Jonathan Cormier over 6 years ago

Thanks Lukas, we actually found this at the end of May and I made a patch for our 3.2 kernel. But it doesn't look like I pushed it to the support site. Sorry about that. I'll look into getting it released.

https://e2e.ti.com/support/arm/sitara_arm/f/791/p/649334/2395792#2395792