AM571x mcspi3 issue.

John Lusby

Right now we're working on a board with two spi controlled sensors on it. Each sensor is on a different spi controller. For some reason we're only able to read back data from the sensor on mcspi1. The reads from mcspi3 all come back as 0s. Both sensors wired to their individual chip select 0 pins with d0 wired to MOSI and d1 to MISO.

       /* These SPI1 values are for e2v0 (cam1), and match the board layout */
       spi1_pins: spi1_pins {
               pinctrl-single,pins = <
                       0x3A4 (PIN_INPUT | MUX_MODE0) /* spi1_sclk SPI1_SCLK */
                       0x3A8 (PIN_INPUT | MUX_MODE0) /* spi1_d1 SPI1_D1 */
                       0x3AC (PIN_OUTPUT | MUX_MODE0) /* spi1_d0 SPI1_D0 */
                       0x3B0 (PIN_OUTPUT | MUX_MODE0) /* spi1_cs0 SPI1_CS0 */
               >;
       };

       /* /1* These SPI3 values are for e2v1 (cam2), and match the board layout *1/ */
       spi3_pins: spi3_pins {
               pinctrl-single,pins = <
                       0x2D4 (PIN_INPUT | MUX_MODE3) /* mcasp1_axr8 SPI3_SCLK */
                       0x2D8 (PIN_INPUT | MUX_MODE3) /* mcasp1_axr9 SPI3_D1 */
                       0x2DC (PIN_OUTPUT | MUX_MODE3) /* mcasp1_axr10 SPI3_D0 */
                       0x2E0 (PIN_OUTPUT | MUX_MODE3) /* mcasp1_axr11 SPI3_CS0 */
               >;
       };

/* e2v0, cam1, SPI control */
&mcspi1 {
    pinctrl-names = "default";
    pinctrl-0 = <&spi1_pins>;

    status = "okay";

    ti,pindir-d0-out-d1-in;

    ev76c560@0 {
        /* compatible = "linux,spidev"; */
        compatible ="ti,ev76c560";
        pinctrl-names = "default";
        pinctrl-0 = <&e2v0_pinmux_core &e2v0_pru_gpios>;

        spi-max-frequency = <5000000>;
        reg = <0x0>;

         port {
             cam1: endpoint {
                 remote-endpoint = <&vin1a>;
                 hsync-active = <1>;
                 vsync-active = <1>;
                 pclk-sample = <0>;
                 input-clock-freq = <32000000>;
                 pixel-clock-freq = <96000000>;
                 mclk-frequency = <48000000>;
                 gpio-reset = <171>; /* gpio6_11 */
             };
         };
    };
};

/* e2v1, cam2, SPI control */
&mcspi3 {
    pinctrl-names = "default";
    pinctrl-0 = <&spi3_pins>;

    status = "okay";

    ti,pindir-d0-out-d1-in;

    ev76c560@0 {
        /* compatible = "linux,spidev"; */
        compatible = "ti,ev76c560";
        pinctrl-names = "default";
        pinctrl-0 = <&e2v1_pinmux_core &e2v1_pru_gpios>;

        spi-max-frequency = <5000000>;
        reg = <0x0>;

         port {
             cam2: endpoint {
                 remote-endpoint = <&vin2a>;
                 hsync-active = <1>;
                 vsync-active = <1>;
                 pclk-sample = <0>;
                 input-clock-freq = <32000000>;
                 pixel-clock-freq = <96000000>;
                 mclk-frequency = <48000000>;
                 gpio-reset = <225>; /* gpio8_1 */
             };
         };
    };
};

over 9 years ago

0 Biser Gatchev-XID over 9 years ago

TI__Guru**** 393215 points

Have you checked that your pinmux settings are not getting overwritten elsewhere in the DTS?

0 John Lusby over 9 years ago in reply to Biser Gatchev-XID

Prodigy 130 points

So here is the fdtdump of those pins being muxed. I'm not really sure how to read this but maybe it will help answer your question

9 spi1_pins {
8 pinctrl-single,pins = <0x000003a4 0x000003ac 0x00000003 0x00000003 0x00000002 0x73000000 0x000002d4 0x000002dc>;
7 linux,phandle = <0x000000d1>;
6 phandle = <0x000000d1>;
5 };
4 spi3_pins {
3 pinctrl-single,pins = <0x000002d4 0x000002dc 0x00000003 0x00000003 0x00000002 0x5f677069 0x0000020d 0x0001000e>;
2 linux,phandle = <0x000000d5>;
1 phandle = <0x000000d5>;
220 };

also the file these are in is the last file that should be parse from what I know of the device tree, all the includes are at the top and there are none in the bottom and there are no other pinctrl entries that reference any of the register offsets used in the spi3 or spi1 pinmux entries.

0 Gunter Schmer over 9 years ago in reply to John Lusby

TI__Genius 14212 points

John,

the pin in question would be this

0x2D8 (PIN_INPUT | MUX_MODE3) /* mcasp1_axr9 SPI3_D1 */

for MISO. Grepping through all of the device tree dts directory, this is not touched (offset 0x2D8 from CTRL_CORE_PAD_ base addr). So your device tree write seems to be the only one.

Can you dump at the kernel level the register 0x4A0036D8 ?

As you have mentioned the external device is driving the MISO line, but maybe the something on the board level or pad conf is still wrong.

Can you maybe switch it into an input GPIO pin and read an external value on the pin?

Regards,
--Gunter

0 John Lusby over 9 years ago in reply to Gunter Schmer

Prodigy 130 points

Hi Gunter,

I was able to dump the register from u-boot, which should be the same muxing as our device tree (and indeed it seems to be upon review of the value output). I get 0x00050003 as the value of the register which seems to indicate input enabled, weak pullup/pulldown disabled, and mux mode3 which is spi3_d1.

Here is how I've muxed the spi pins in u-boot

~ 626     {MCASP1_AXR8,     (M3 | PIN_OUTPUT)},   /* mcasp1_axr8.spi3_sclk */
~   1     {MCASP1_AXR9,     (M3 | PIN_INPUT)},    /* mcasp1_axr9.spi3_d1 */
~   2     {MCASP1_AXR10,    (M3 | PIN_OUTPUT)},   /* mcasp1_axr10.spi3_d0 */
~   3     {MCASP1_AXR11,    (M3 | PIN_INPUT_PULLUP)}, /* mcasp1_axr11.spi3_cs0 */
~   4     {MCASP1_AXR12,    (M3 | PIN_INPUT_PULLUP)}, /* mcasp1_axr12.spi3_cs1 */

0 Biser Gatchev-XID over 9 years ago in reply to John Lusby

TI__Guru**** 393215 points

~ 626 {MCASP1_AXR8, (M3 | PIN_OUTPUT)}, /* mcasp1_axr8.spi3_sclk */

Should be changed to:

~ 626 {MCASP1_AXR8, (M3 | PIN_INPUT)}, /* mcasp1_axr8.spi3_sclk */

Read the Note below Table 24-288 in the AM572X TRM.

0 John Lusby over 9 years ago in reply to Biser Gatchev-XID

Prodigy 130 points

Hello Biser,

I've made the indicated change but it has had no effect. We actually already had that muxed as input via the device tree which should have made that change in the board's mux_data.h file redundant, but now it is consistent. Here is the current muxing which still shows the same problem. We've temporarily worked around the issue by faking all the reads on the bad spi bus based on what the read properly does on the good spi bus so we were able to get the imager up and working but we still have the inability to read anything back on SPI3

from mux_data.h
~ 626 {MCASP1_AXR8, (M3 | PIN_INPUT)}, /* mcasp1_axr8.spi3_sclk */
~ 1 {MCASP1_AXR9, (M3 | PIN_INPUT)}, /* mcasp1_axr9.spi3_d1 */
~ 2 {MCASP1_AXR10, (M3 | PIN_OUTPUT)}, /* mcasp1_axr10.spi3_d0 */
~ 3 {MCASP1_AXR11, (M3 | PIN_OUTPUT_PULLUP)}, /* mcasp1_axr11.spi3_cs0 */
~ 4 {MCASP1_AXR12, (M3 | PIN_OUTPUT_PULLUP)}, /* mcasp1_axr12.spi3_cs1 */

from our boardlevel dts file
213 spi3_pins: spi3_pins {
1 pinctrl-single,pins = <
2 0x2D4 (PIN_INPUT | MUX_MODE3) /* mcasp1_axr8 SPI3_SCLK */
3 0x2D8 (PIN_INPUT | MUX_MODE3) /* mcasp1_axr9 SPI3_D1 */
4 0x2DC (PIN_OUTPUT | MUX_MODE3) /* mcasp1_axr10 SPI3_D0 */
5 0x2E0 (PIN_OUTPUT | MUX_MODE3) /* mcasp1_axr11 SPI3_CS0 */
6 >;

This has working writes but broken reads on spi3. here is our muxing for spi 1 which is working for writes and reads

from mux_data.h
~ 678 {SPI1_SCLK, (M0 | PIN_INPUT)}, /* spi1_sclk.spi1_sclk */
~ 1 {SPI1_D1, (M0 | PIN_INPUT)}, /* spi1_d1.spi1_d1 */
~ 2 {SPI1_D0, (M0 | PIN_OUTPUT)}, /* spi1_d0.spi1_d0 */
~ 3 {SPI1_CS0, (M0 | PIN_OUTPUT_PULLUP)}, /* spi1_cs0.spi1_cs0 */
~ 4 {SPI1_CS1, (M0 | PIN_OUTPUT_PULLUP)}, /* spi1_cs1.spi1_cs1 */

from dts file
203 spi1_pins: spi1_pins {
1 pinctrl-single,pins = <
2 0x3A4 (PIN_INPUT | MUX_MODE0) /* spi1_sclk.spi1_sclk */
3 0x3A8 (PIN_INPUT | MUX_MODE0) /* spi1_d1.spi1_d1, (MISO) */
4 0x3AC (PIN_OUTPUT | MUX_MODE0) /* spi1_d0.spi1_d0, (MOSI) */
5 0x3B0 (PIN_OUTPUT | MUX_MODE0) /* spi1_cs0.spi1_cs0 */
6 >;
7 };

0 Gunter Schmer over 9 years ago in reply to John Lusby

TI__Genius 14212 points

John,

could you still dump the register 0x4A0036D8 from the kernel level, after the device tree has taken effect?

I think you can do it with "dev2mem"

Could you maybe switch the MISO pin into a GPO and drive it, not sure if this is possible with the sensor in place ... but it could help verify that the electrical connection is good.

Regards,

--Gunter

0 John Lusby over 9 years ago in reply to Gunter Schmer

Prodigy 130 points

I can confirm that when muxed as a gpio I'm able to drive it high (1.8v) and low (0v). Our EE guy says that 1.8v high is correct for this ball because vddshv3 power domain is 1.8V.

Heres the output of devmem2

root@am57xx-evm:~# devmem2 0x4A0036D8
/dev/mem opened.
Memory mapped at address 0xb6fe0000.
Read at address 0x4A0036D8 (0xb6fe06d8): 0x00050003

As a side note we rewired the second imager to spi2 and everything works.

Processors

Processors forum

AM571x mcspi3 issue.