This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

  • Resolved

Linux/AM4378: Spidev does not output on pins

Intellectual 610 points

Replies: 25

Views: 8788

Part Number: AM4378

Tool/software: Linux

Hi Everybody!

I recently got my spidev devices registered in /dev (see here for details). 

My devices don't seem to work unfortunately.  I have only scoped out spidev1.1 so far.  I can open the device.  When I configre it I do get messages complaining about not using DMA (see below).  And then I get a TXS timed out message.

I am using a program really similar to this one.  I just added a ton of printing and slowed things down so that I could tell which actions were causing the system log messages.

Here is the output.

root@am437x-evm:/ace/bin# ./helloSpi -C 301
helloSpi ...
    ...Options selected
        device = /dev/spidev1.1
        speed = 24000000
        delay = 0
        bits = 8
        mode = 0x04
    ...Creating device
    ...Setting SPI option
    ...Opening file handle
    ...Committing options     <-- 3 ioctl calls in here
[62332.673461] spidev spi1.1: not using DMA for McSPI (-19)
[62332.678907] spidev spi1.1: not using DMA for McSPI (-19)
[62332.689027] spidev spi1.1: not using DMA for McSPI (-19)
    ...Setting up data transfer
        TX = 0x03 0x01 0x00 0x00 0x00 0x00 0x00 0x00
        RX = 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
    ...Performing ioctl data transfer   <-- 1 ioctl call in here
[62340.712144] spidev spi1.1: TXS timed out
    ...Receive buffer
        RX = 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
Good bye!

I had our electrical team scope the clk, miso, mosi, and cs pin for spidex1.1 and there is no activity.

I also see the cs pin held low the entire time.  I think it should only go low when the spi master wants to send data to or retrieve data from that particular device.

Here is my pin mux...

spi2_internal_pins_default: spi2_internal_pins_default {
    pinctrl-single,pins = <
        0x260 ( PIN_OUTPUT | INPUT_EN | MUX_MODE0 ) /* (N20) spi2_sclk.spi2_sclk */
        0x264 ( PIN_OUTPUT | MUX_MODE0 )            /* (P22) spi2_d0.spi2_d0 */
        0x268 ( PIN_INPUT_PULLUP | MUX_MODE0 )      /* (P20) spi2_d1.spi2_d1 */
        0x1b0 ( PIN_OUTPUT | MUX_MODE4 )            /* (AE17) cam0_hd.spi2_cs1 */
        0x1c4 ( PIN_OUTPUT | MUX_MODE4 )            /* (AB19) cam0_data8.spi2_cs2 */
    >;

}

&spi2 {
    compatible = "ti,omap2-mcspi";
    pinctrl-names = "default";
    pinctrl-0 = <&spi2_internal_pins_default>;
    status = "okay";

        ti,spi-num-cs = <4>;
        ti,pindir-d0-out-d1-in = <1>;

ksz8895@1 {
    compatible = "rohm,dh2228fv";
    spi-max-frequency = <100000>;
    reg = <0x1>;
    status = "okay";
    #address-cells = <1>;
    #size-cells = <0>;
};
ksz8895@2 {
    compatible = "rohm,dh2228fv";
    spi-max-frequency = <100000>;
    reg = <0x2>;
    status = "okay";
    #address-cells = <1>;
    #size-cells = <0>;
};

};

Here are (what I think are pertinent) defconfig settings. In fact here's everything SPI related.  I highlighted the ones I think actually matter

root@am437x-evm:/ace/bin# cat /proc/config.gz|gunzip|grep SPI|grep \# -v|grep SPIN -v
CONFIG_REGMAP_SPI=y
CONFIG_MTD_SPI_NOR=y
CONFIG_SPI_CADENCE_QUADSPI=y
CONFIG_WLCORE_SPI=m
CONFIG_INPUT_ADXL34X_SPI=m
CONFIG_SPI=y
CONFIG_SPI_MASTER=y
CONFIG_SPI_BITBANG=m
CONFIG_SPI_GPIO=m
CONFIG_SPI_OMAP24XX=y
CONFIG_SPI_TI_QSPI=y
CONFIG_SPI_SPIDEV=y
CONFIG_SND_SOC_I2C_AND_SPI=y
CONFIG_RTC_I2C_AND_SPI=y

I've seen various posts about differing pinmux settings.  I've seen Biser say the clk needs to be an input (I tried, no change), I've seen another post that said they had success with clk as output with input_en flag.  So I'm not sure what is the "right" answer. 

All thoughts/suggestions/troubleshooting tips are welcome.

Thanks in advance!

Nathan

  • In reply to Nathan Wright:

    Found something...

    [ 9935.309422] spidev spi1.2: not using DMA for McSPI (-19)

    .. appear to be benign. It is a warning that the transfer is so small it will use PIO instead of DMA.
  • In reply to Yordan Kovachev:

    Hi Yordan,

    You said "In latest SDKs pinmux is done in u-boot. "  Can you expound on that?  My u-boot dts is relatively unchanged from am437x-gp-evm.  I made my customizations in board-support/linux.../dts.  Only changing the dts in board-support/linux... has seemed to work so far for me. 

    Are these related?  Is one dts file have precedence over the other?

    Thanks,

    Nathan

  • In reply to Nathan Wright:

    Nathan,

    Kernel dts should overwrite the settings. Here is what I did on my BBB (I don't have my hands on AM437x board at the moment), however kernel settings should be the same on AM437x, with the exception of the pinmux of course:

            spi1_pins: spi1_pins {

                   pinctrl-single,pins = <

                           AM33XX_IOPAD(0x990, PIN_INPUT_PULLUP | MUX_MODE3) /*mcasp0_aclkx.spi1_sclk*/

                           AM33XX_IOPAD(0x99c, PIN_INPUT | MUX_MODE3) /*mcasp0_ahclkr.spi1_cs0*/

                           AM33XX_IOPAD(0x994, PIN_INPUT | MUX_MODE3) /* mcasp0_fsx.spi1_d0*/

                           AM33XX_IOPAD(0x998, PIN_INPUT | MUX_MODE3) /*mcasp0_axr2.spi1_d1*/

                   >;

          };

      &spi1 {

      status="okay";

      pinctrl-names = "default";

      pinctrl-0 = <&spi1_pins>;

      spidev@0 {

            compatible = "rohm,dh2228fv";

            spi-max-frequency = <5000000>;

            reg = <0>;

            status = "okay";

      };

    };

    Perhaps I wasn't clear enough there is no requirement to always have cs0 configured. You can use just cs1 and cs2, if you don't need cs0.

    With the above settings I execute root@am335x-evm:~# echo "BABACECA" > /dev/spidev1.0 in the user space and I get the following scope waveforms:

    As you can see the SPI interface is working fine. 

    Best Regards, 
    Yordan

     


     Please make sure you read the forum guidelines first.

  • In reply to Yordan Kovachev:

    Yordan and Nathan,

    I have been doing some experimenting on this as well. So I was able to replicate the pinmux settings Yordan used on my BBB, and I think we can all agree that if the pinmux is set correctly, the device will behave as configured.

    I have also had success getting multiple chip selects working on the same SPI peripheral. In essence I added an additional chip select (D17) to the spi1_pins:

    spi1_pins: spi1_pins {

    pinctrl-single,pins = <

    AM33XX_IOPAD(0x990, PIN_INPUT_PULLUP | MUX_MODE3) /*mcasp0_aclkx.spi1_sclk*/

    AM33XX_IOPAD(0x99c, PIN_INPUT | MUX_MODE3) /*mcasp0_ahclkr.spi1_cs0*/

    AM33XX_IOPAD(0x97C,PIN_INPUT|MUX_MODE4) /*uart1_rtsn.spi1_cs0*/

    AM33XX_IOPAD(0x994, PIN_INPUT | MUX_MODE3) /* mcasp0_fsx.spi1_d0*/

    AM33XX_IOPAD(0x998, PIN_INPUT | MUX_MODE3) /*mcasp0_axr2.spi1_d1*/

    >;

    };

    Note that this pin (D17) is also used as an I2C pin to read the EEPROMS on BBB capes. I commented this out to avoid creating any confusion as to what the pin was used for, and disabled the i2c2 entry just in case.

    Then I redefined spi1 as:

    &spi1 {

    status="okay";

    pinctrl-names = "default";

    pinctrl-0 = <&spi1_pins>;

    ti,spi-num-cs=<2> /* I'm not sure if this is strictly necessary, but I haven't tried removing*/

    spidev@0 {

    compatible = "rohm,dh2228fv";

    spi-max-frequency = <5000000>;

    reg = <0>;

    status = "okay";

    };

    spidev@1 {

    compatible = "rohm,dh2228fv";

    spi-max-frequency = <5000000>;

    reg = <1>;

    status = "okay";

    };

    };

    I was able to write out data on both /dev/spidev1.0 and /dev/spidev1.1 using this configuration.

    The key difference for me was not using the "compatible="ti,omap2-mcspi;" line. When I did that I was getting the same errors Nathan was seeing with the TX timeouts. 

    Hope this helps!

    Munan

  • In reply to Munan Xu:

    Thanks Munan,

    Changing compatible from "ti,omap2-mcspi;" back to "ti,am4372-mcspi","ti,omap4-mcspi"; seems to have resolved the problem. The switch out there even replies now.

    Thanks everyone for your help,
    Nathan

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.