AM5728: McSPI4 Master issue

Yvan Pearson

Part Number: AM5728

Board: Beagleboard X15, using AM5728

Using build root to bring up x15 board

Modifying DTS and pinmux to get MCSPI4 master to pins:

/* SCLK N7 gpmc_a8.spi4_sclk --> P16.9  */
/* MISO R4 gpmc_a9.spi4_d1   --> P16.37 */
/* MOSI N9 gpmc_a10.spi4_d0  --> P16.14 */
/* CS0  P9 gpmc_a11.spi4_cs0 --> P16.44 */

Files I'm patching are in kernel/ and uboot:

linux-4.9/arch/arm/boot/dts/am57xx-beagle-x15.dts

+&dra7_pmx_core {
+ mcspi4_pins_default: mcspi4_pins_default {
+ pinctrl-single,pins = <
+ 0x60 (PIN_INPUT_PULLUP | MUX_MODE8) /* gpmc_a8.spi4_sclk --> P16.9 */
+ 0x64 (PIN_INPUT_PULLUP | MUX_MODE8) /* gpmc_a9.spi4_d1 --> P16.37 */
+ 0x68 (PIN_OUTPUT_PULLUP | MUX_MODE8) /* gpmc_a10.spi4_d0 --> P16.14 */
+ 0x6C (PIN_OUTPUT_PULLUP | MUX_MODE8) /* gpmc_a11.spi4_cs0 --> P16.44 */
+ >;
+ };
+};
+
+&mcspi4 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&mcspi4_pins_default>;
+ spidev@0 {
+ reg = <0>;
+ compatible = "spidev";
+ spi-max-frequency = <1000000>;
+ };
+};

uboot-2016.11/arch/arm/dts/am57xx-beagle-x15.dts

+ mcspi4_pins_default: mcspi4_pins_default {
+ pinctrl-single,pins = <
+ 0x60 (PIN_INPUT_PULLUP | MUX_MODE8) /* gpmc_a8.spi4_sclk --> P16.9 */
+ 0x64 (PIN_INPUT_PULLUP | MUX_MODE8) /* gpmc_a9.spi4_d1 --> P16.37 */
+ 0x68 (PIN_OUTPUT_PULLUP | MUX_MODE8) /* gpmc_a10.spi4_d0 --> P16.14 */
+ 0x6C (PIN_OUTPUT_PULLUP | MUX_MODE8) /* gpmc_a11.spi4_cs0 --> P16.44 */
+ >;
+ };
+
@@ -531,6 +540,17 @@
};
};

+&mcspi4 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&mcspi4_pins_default>;
+ spidev@0 {
+ reg = <0>;
+ compatible = "spidev";
+ spi-max-frequency = <1000000>;
+ };
+};
+


uboot-2016.11/board/ti/am57xx/mux_data.h

- {GPMC_A8, (M2 | PIN_INPUT_PULLDOWN | MANUAL_MODE)}, /* gpmc_a8.vin3a_hsync0 */
- {GPMC_A9, (M2 | PIN_INPUT_PULLDOWN | MANUAL_MODE)}, /* gpmc_a9.vin3a_vsync0 */
- {GPMC_A10, (M2 | PIN_INPUT_PULLDOWN | MANUAL_MODE)}, /* gpmc_a10.vin3a_de0 */
- {GPMC_A11, (M2 | PIN_INPUT_PULLDOWN | MANUAL_MODE)}, /* gpmc_a11.vin3a_fld0 */
+ #if 1 // SPI 4
+ {GPMC_A8, (M8 | PIN_INPUT_PULLUP | MANUAL_MODE)}, /* N7 gpmc_a8.spi4_sclk --> P16.9 */
+ {GPMC_A9, (M8 | PIN_INPUT_PULLUP | MANUAL_MODE)}, /* R4 gpmc_a9.spi4_d1 --> P16.37 */
+ {GPMC_A10, (M8 | PIN_OUTPUT_PULLUP | MANUAL_MODE)}, /* N9 gpmc_a10.spi4_d0 --> P16.14 */
+ {GPMC_A11, (M8 | PIN_OUTPUT_PULLUP | MANUAL_MODE)}, /* P9 gpmc_a11.spi4_cs0 --> P16.44 */
+ #endif

After booting a /dev/spi1.0 I'm able to use python spidev or just 'echo '123' > /dev/spi1.0 with feedback:

Jan 1 00:11:06 buildroot kern.debug kernel: [ 666.472968] spidev spi1.0: setup: speed 100000, sample leading edge, clk normal
Jan 1 00:11:06 buildroot kern.debug kernel: [ 666.472992] spidev spi1.0: setup mode 0, 8 bits/w, 100000 Hz max --> 0
Jan 1 00:11:06 buildroot kern.debug kernel: [ 666.473010] spidev spi1.0: setup: speed 1000000, sample leading edge, clk normal
Jan 1 00:11:06 buildroot kern.debug kernel: [ 666.473024] spidev spi1.0: setup mode 0, 8 bits/w, 1000000 Hz max --> 0
Jan 1 00:11:06 buildroot kern.debug kernel: [ 666.473031] spidev spi1.0: spi mode 0
Jan 1 00:11:06 buildroot kern.debug kernel: [ 666.473095] spidev spi1.0: setup: speed 100000, sample leading edge, clk normal
Jan 1 00:11:06 buildroot kern.debug kernel: [ 666.473447] spidev spi1.0: setup: speed 1000000, sample leading edge, clk normal

And I can see it on the scope.

The mystery is that serial data is coming from the MISO, and MOSI appears to be doing nothing.

The code specifies

spi4_d1 --> MISO,

spi4_d0 ---> MOSI

But data is exiting from spi4_d1, and not spi4_d0.

Even more strange is if I make spi4_d1 as MOSI, and spi4_d0 as MISO I get the same result.

I tried using devmem2, but it crashes on most addresses I tried.

I appreciate any responses! =)

thanks,

over 6 years ago

0 Pavel Botev over 6 years ago

TI__Guru**** 170625 points

Hi Yvan,

I would suggest you to put all your McSPI pinmux settings in MLO/SPL mux_data.h.

Then I would suggest you to dump and explore below registers:

CTRL_CORE_PAD_GPMC_A8 0x4A003460

CTRL_CORE_PAD_GPMC_A9 0x4A003464

CTRL_CORE_PAD_GPMC_A10 0x4A003468

CTRL_CORE_PAD_GPMC_A11 0x4A00346C

CM_L4PER_MCSPI4_CLKCTRL 0x4A009808

MCSPI_CH0CONF 0x480BA12C

Also, it seems to me that this use case in NOT supported by HW, as MCSPI_CH0CONF[18] IS bit selects D0 for input OR D1 for input. This bit always select one data pin (D0 or D1) to be input.

Regards,
Pavel

0 Yvan Pearson over 6 years ago in reply to Pavel Botev

Intellectual 850 points

Update:

I believe adding

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

To the device tree partially fixed the issue. SCLK, MOSI, and CS seems to operate as you would expect but data coming into MISO is read as all zeros. Note that data on MISO can be observed on a a logic analyzer and it was confirmed to be connected to the AM57xx on P16.37 (beagle x15)

I will do as you suggested and report back soon.

0 Yvan Pearson over 6 years ago in reply to Yvan Pearson

Intellectual 850 points

Here is the dump of all the registers:

Value at address 0x4A003460 (0xb6f28460): 0x60008
Value at address 0x4A003464 (0xb6f17464): 0x60008
Value at address 0x4A003468 (0xb6f33468): 0x20008
Value at address 0x4A00346C (0xb6fe146c): 0x20008
Value at address 0x4A009808 (0xb6f4f808): 0x30000
Value at address 0x480BA12C (0xb6fe012c): 0x200603D4

0 Yvan Pearson over 6 years ago in reply to Yvan Pearson

Intellectual 850 points

Just to re-iterate.

CS, MOSI, SCLK work as expected.
MISO data is observed on my logical analyzer
data read from MISO reads all zeros at this moment

0 Yvan Pearson over 6 years ago in reply to Yvan Pearson

Intellectual 850 points

Resolved:

There was a pinmux conflict, the following fixed it:

+	#if 0
 	{MMC3_DAT4, (M1 | PIN_INPUT_PULLDOWN)},	/* mmc3_dat4.spi4_sclk */
 	{MMC3_DAT5, (M1 | PIN_INPUT_PULLDOWN)},	/* mmc3_dat5.spi4_d1 */
 	{MMC3_DAT6, (M1 | PIN_INPUT_PULLDOWN)},	/* mmc3_dat6.spi4_d0 */
 	{MMC3_DAT7, (M1 | PIN_INPUT_PULLUP)},	/* mmc3_dat7.spi4_cs0 */
+	#endif

0 Pavel Botev over 6 years ago in reply to Yvan Pearson

TI__Guru**** 170625 points

Yvan,

Are you able to transmit (output) data on both spi4_d0 and spi4_d1 pins now?

Regards,
Pavel

0 Yvan Pearson over 6 years ago in reply to Pavel Botev

Intellectual 850 points

Yes, SPI works great. Thanks for the response and support.

Processors

Processors forum

AM5728: McSPI4 Master issue