SPI troubles

SPI troubles

[Ben Gamari]

Hey all,

As I've mentioned here in the past, I am currently putting together a board for
doing analog data acquisition on the BeagleBoard platform. Unfortunately, I
have wasted nearly the entire weekend trying to accomplish the (one would
think) simple goal of recieving data with the McSPI controllers (in particular,
run a loop-back test on McSPI3 with spidev_test).

While I can reliably see a signal sent on the SIMO line, I have not once been
able to recieve anything but zeros in return. I have verified that the the SOMI
ball works as expected as a GPIO input. I have tried every pinmux configuration
imaginable (using both the kernel and u-boot) and yet I have still met no
success. It seems like this has been an issue in the past[1] and it seems that
at one point SPI was working[2], yet I have been completely unable to reproduce
this result.

When measuring the SIMO signal on the expansion connector with my daughterboard
connected, I noticed that the daughterboard's level shifter appeared to be
driving the signal higher than it should, to ~2.9 Volts. I then checked the
1.8V rail voltage and found that it too was higher than expected, again at 2.9
volts. When I unplug the daughterboard, the 1.8V rail voltage returns to its
expected value.

I'm both perplexed and concerned with this behavior. I completely fail to
see how my board is raising the voltage on the 1.8V rail (schematic available
at [3]).  While the BeagleBoard seems quite stable, I'm very concerned that
perhaps the daughterboard over-drove the SIMO ball and burned out some subset
of the OMAP.  Regardless, as mentioned earlier, I have verified the
functionality of the same ball as a GPIO input. Thus, I am thoroughly confused.
Is it possible that the ball's GPIO receiver could remain functional while the
McSPI receiver is burned out?

I am using a 2.6.32 kernel and can see in debugfs that the pinmux is configured
correct, with only the sdmmc2_dat0 pin exposing the McSPI3_SOMI signal. The
kernel patch I'm using to configure the muxes and spi controllers is included
below. As can be seen, I've also tried using the spi-gpio driver, but
unfortunately I wasn't even able to get it producing data on SIMO.

I've tried this using two daughterboards on two different Beagles (a B7 and a
new C4) with identical results on both.  If anyone has any ideas at all, I would
love to hear them. I am really unsure of how to proceed at this point and I'm
quickly running out of time to devote to this project. I've included my kernel
patch below and the daughterboard design is available in Eagle format at [3].

Thanks,

- Ben


P.S. It seems to me that SPI is one of the more important interfaces on the
BoardBoard. As such, it would be really nice if there was a standard test of
SPI functionality. It seems many people have struggled to get SPI working on
the BeagleBoard and not too many have succeeded. A standard prescription would
be extremely useful.

P.P.S. Is it just me or does the omap_pinmux interface need some refinement.
Using it has been an exercise in frustration, between extremely sparse
documentation, quirky behavior (I still haven't figure out how to get gpio_130
configured.  omap_mux_init_gpio fails with "multiple paths for gpio130" whereas
omap_mux_init_signal fails to even recognize the signal name), and general
complexity. The idea behind the interface seems excellent, but it seems it
hasn't been used enough not to be a complete pain in the ass to figure out and
use.


[1] http://markmail.org/message/2vbfuz7bltvrk6g3#query:beagle%20spi%20zeros+page:1+mid:wduqfhs4ur373ehp+state:results
[2] http://groups.google.com/group/beagleboard/browse_thread/thread/42988f0e14db0f01/816397901ec999c4?lnk=gst&q=Balister+&pli=1
[3] http://goldnerlab.physics.umass.edu/git?p=tracker-board.git;a=summary



diff --git a/arch/arm/mach-omap2/board-omap3beagle.c b/arch/arm/mach-omap2/board-omap3beagle.c
index 231cb4e..b23c5a5 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -12,6 +12,10 @@
  * published by the Free Software Foundation.
  */
 
+//#define BEAGLE_GPIO_SPI
+
+
+
 #include <linux/kernel.h>
 #include <linux/init.h>
 #include <linux/platform_device.h>
@@ -28,6 +32,7 @@
 #include <linux/mtd/partitions.h>
 #include <linux/mtd/nand.h>
 
+#include <linux/spi/spi.h>
 #include <linux/regulator/machine.h>
 #include <linux/i2c/twl.h>
 
@@ -372,6 +377,159 @@ static struct platform_device *omap3_beagle_devices[] __initdata = {
 	&keys_gpio,
 };
 
+#ifndef BEAGLE_GPIO_SPI
+
+static void __init omap3_beagle_config_mcspi3_mux(void)
+{
+	omap_mux_init_signal("sdmmc2_clk.mcspi3_clk", OMAP_PIN_OUTPUT);
+	omap_mux_init_signal("sdmmc2_dat3.mcspi3_cs0", OMAP_PIN_OUTPUT);
+	omap_mux_init_signal("sdmmc2_dat2.mcspi3_cs1", OMAP_PIN_OUTPUT);
+	omap_mux_init_signal("sdmmc2_cmd.mcspi3_simo", OMAP_PIN_OUTPUT);
+	omap_mux_init_signal("sdmmc2_dat0.mcspi3_somi", OMAP_PIN_INPUT_PULLUP);
+}
+
+static void __init omap3_beagle_config_mcspi4_mux(void)
+{
+	omap_mux_init_signal("mcbsp1_clkr.mcspi4_clk", OMAP_PIN_OUTPUT);
+	omap_mux_init_signal("mcbsp1_fsx.mcspi4_cs0", OMAP_PIN_OUTPUT);
+	omap_mux_init_signal("mcbsp1_dx.mcspi4_simo", OMAP_PIN_OUTPUT);
+	omap_mux_init_signal("mcbsp1_dr.mcspi4_somi", OMAP_PIN_INPUT_PULLUP);
+}
+
+static struct spi_board_info beagle_mcspi_board_info[] = {
+	// spi 3.0
+	{
+		.modalias	= "spidev",
+		.max_speed_hz	= 48000000, //48 Mbps
+		.bus_num	= 3,
+		.chip_select	= 0,	
+		.mode = SPI_MODE_1,
+	},
+
+	// spi 3.1
+	{
+		.modalias	= "spidev",
+		.max_speed_hz	= 48000000, //48 Mbps
+		.bus_num	= 3,
+		.chip_select	= 1,	
+		.mode = SPI_MODE_1,
+	},
+
+	// spi 4.0
+	{
+		.modalias	= "spidev",
+		.max_speed_hz	= 48000000, //48 Mbps
+		.bus_num	= 4,
+		.chip_select	= 0,	
+		.mode = SPI_MODE_1,
+	},
+};
+
+#else /* BEAGLE_GPIO_SPI */
+#include <linux/spi/spi_gpio.h>
+
+#define SPI3_CLK 130
+#define SPI3_SOMI 132
+#define SPI3_SIMO 131
+#define SPI3_CS0 135
+#define SPI3_CS1 134
+
+#define SPI4_CLK 156
+#define SPI4_SOMI 159
+#define SPI4_SIMO 158
+#define SPI4_CS0 161
+
+#define GPIO_SPI_PIN(pin, dir, name)  \
+	omap_mux_init_gpio(pin, OMAP_PIN_##dir); \
+	gpio_request(pin, name); \
+	gpio_export(pin, true);
+
+static void __init omap3_beagle_config_gpio_spi3_mux(void)
+{
+	GPIO_SPI_PIN(SPI3_CLK, OUTPUT, "spi3_clk");
+	GPIO_SPI_PIN(SPI3_SIMO, OUTPUT, "spi3_simo");
+	GPIO_SPI_PIN(SPI3_SOMI, INPUT, "spi3_somi");
+	GPIO_SPI_PIN(SPI3_CS0, OUTPUT, "spi3_cs0");
+	GPIO_SPI_PIN(SPI3_CS1, OUTPUT, "spi3_cs1");
+}
+
+static void __init omap3_beagle_config_gpio_spi4_mux(void)
+{
+	GPIO_SPI_PIN(SPI4_CLK, OUTPUT, "spi4_clk");
+	GPIO_SPI_PIN(SPI4_SIMO, OUTPUT, "spi4_simo");
+	GPIO_SPI_PIN(SPI4_SOMI, INPUT, "spi4_somi");
+	GPIO_SPI_PIN(SPI4_CS0, OUTPUT, "spi4_cs0");
+}
+
+static struct spi_gpio_platform_data beagle_gpio_spi_platform_data[] = {
+	// spi 3
+	{
+		.sck = SPI3_CLK,
+		.miso = SPI3_SOMI,
+		.mosi = SPI3_SIMO,
+		.num_chipselect = 2,
+	},
+
+	// spi 4
+	{
+		.sck = SPI4_CLK,
+		.miso = SPI4_SOMI,
+		.mosi = SPI4_SIMO,
+		.num_chipselect = 1,
+	},
+};
+
+static struct platform_device beagle_gpio_spi_platform_device[] = {
+	// spi .
+	{
+		.name		= "spi_gpio",
+		.id		= 3,
+		.dev		= {
+			.platform_data = &beagle_gpio_spi_platform_data[0],
+		},
+	},
+
+	// spi 4
+	{
+		.name		= "spi_gpio",
+		.id		= 4,
+		.dev		= {
+			.platform_data = &beagle_gpio_spi_platform_data[1],
+		},
+	},
+};
+
+static struct spi_board_info beagle_gpio_spi_board_info[] = {
+	// spi 3.0
+	{
+		.modalias	= "spidev",
+		.max_speed_hz	= 48000000, //48 Mbps
+		.bus_num	= 3,
+		.mode = SPI_MODE_1,
+		.controller_data = (void *) SPI3_CS0,
+	},
+
+	// spi 3.1
+	{
+		.modalias	= "spidev",
+		.max_speed_hz	= 48000000, //48 Mbps
+		.bus_num	= 3,
+		.mode = SPI_MODE_1,
+		.controller_data = (void *) SPI3_CS1,
+	},
+
+	// spi 4.0
+	{
+		.modalias	= "spidev",
+		.max_speed_hz	= 48000000, //48 Mbps
+		.bus_num	= 4,
+		.mode = SPI_MODE_1,
+		.controller_data = (void *) SPI4_CS0,
+	},
+};
+
+#endif /* BEAGLE_GPIO_SPI */
+
 static void __init omap3beagle_flash_init(void)
 {
 	u8 cs = 0;
@@ -432,12 +590,30 @@ static struct omap_board_mux board_mux[] __initdata = {
 
 static void __init omap3_beagle_init(void)
 {
+	int i;
+
 	omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
 	omap3_beagle_i2c_init();
 	platform_add_devices(omap3_beagle_devices,
 			ARRAY_SIZE(omap3_beagle_devices));
 	omap_serial_init();
 
+#ifndef BEAGLE_GPIO_SPI
+	printk(KERN_ERR "Using McSPI for SPI\n");
+	omap3_beagle_config_mcspi3_mux();
+	omap3_beagle_config_mcspi4_mux();
+	spi_register_board_info(beagle_mcspi_board_info,
+			ARRAY_SIZE(beagle_mcspi_board_info));
+#else
+	printk(KERN_ERR "Using GPIO for SPI\n");
+	omap3_beagle_config_gpio_spi3_mux();
+	omap3_beagle_config_gpio_spi4_mux();
+	for (i=0; i<3; i++)
+		platform_device_register(&beagle_gpio_spi_platform_device[i]);
+	spi_register_board_info(beagle_gpio_spi_board_info,
+			ARRAY_SIZE(beagle_gpio_spi_board_info));
+#endif
+
 	omap_mux_init_gpio(170, OMAP_PIN_INPUT);
 	gpio_request(170, "DVI_nPD");
 	/* REVISIT leave DVI powered down until it's needed ... */
@@ -458,6 +634,7 @@ static void __init omap3_beagle_map_io(void)
 	omap2_map_common_io();
 }
 
+
 MACHINE_START(OMAP3_BEAGLE, "OMAP3 Beagle Board")
 	/* Maintainer: Syed Mohammed Khasim - http://beagleboard.org */
 	.phys_io	= 0x48000000,

Re: [spi-devel-general] SPI troubles

[jassi brar]

On Mon, Mar 15, 2010 at 11:44 AM, Ben Gamari <bgamari.foss@gmail.com> wrote:
> While I can reliably see a signal sent on the SIMO line, I have not once been
> able to recieve anything but zeros in return. I have verified that the the SOMI
> ball works as expected as a GPIO input.
a) You might as well want to verify your SPIDEV setup by using the
same pins in GPIO mode
and controlling them by gpio-bitbanging i/f  ... first on both boards
and then on either, to more
accurately diagnose the problem).
b) Maybe line-strength settings should be checked, if available, of
the relevant pins?

hth

Re: SPI troubles

[Philip Balister]

On 03/14/2010 10:44 PM, Ben Gamari wrote:
> Hey all,
>
> As I've mentioned here in the past, I am currently putting together a board for
> doing analog data acquisition on the BeagleBoard platform. Unfortunately, I
> have wasted nearly the entire weekend trying to accomplish the (one would
> think) simple goal of recieving data with the McSPI controllers (in particular,
> run a loop-back test on McSPI3 with spidev_test).

For some reason you need to set the clock pin as an input. Here is the 
config for mcspi1 that is working for me:

MUX_VAL(CP(MCSPI1_CLK),         (IEN  | PTD | DIS | M0)) /*McSPI1_CLK*/\

(from u-boot)

Philip



>
> While I can reliably see a signal sent on the SIMO line, I have not once been
> able to recieve anything but zeros in return. I have verified that the the SOMI
> ball works as expected as a GPIO input. I have tried every pinmux configuration
> imaginable (using both the kernel and u-boot) and yet I have still met no
> success. It seems like this has been an issue in the past[1] and it seems that
> at one point SPI was working[2], yet I have been completely unable to reproduce
> this result.
>
> When measuring the SIMO signal on the expansion connector with my daughterboard
> connected, I noticed that the daughterboard's level shifter appeared to be
> driving the signal higher than it should, to ~2.9 Volts. I then checked the
> 1.8V rail voltage and found that it too was higher than expected, again at 2.9
> volts. When I unplug the daughterboard, the 1.8V rail voltage returns to its
> expected value.
>
> I'm both perplexed and concerned with this behavior. I completely fail to
> see how my board is raising the voltage on the 1.8V rail (schematic available
> at [3]).  While the BeagleBoard seems quite stable, I'm very concerned that
> perhaps the daughterboard over-drove the SIMO ball and burned out some subset
> of the OMAP.  Regardless, as mentioned earlier, I have verified the
> functionality of the same ball as a GPIO input. Thus, I am thoroughly confused.
> Is it possible that the ball's GPIO receiver could remain functional while the
> McSPI receiver is burned out?
>
> I am using a 2.6.32 kernel and can see in debugfs that the pinmux is configured
> correct, with only the sdmmc2_dat0 pin exposing the McSPI3_SOMI signal. The
> kernel patch I'm using to configure the muxes and spi controllers is included
> below. As can be seen, I've also tried using the spi-gpio driver, but
> unfortunately I wasn't even able to get it producing data on SIMO.
>
> I've tried this using two daughterboards on two different Beagles (a B7 and a
> new C4) with identical results on both.  If anyone has any ideas at all, I would
> love to hear them. I am really unsure of how to proceed at this point and I'm
> quickly running out of time to devote to this project. I've included my kernel
> patch below and the daughterboard design is available in Eagle format at [3].
>
> Thanks,
>
> - Ben
>
>
> P.S. It seems to me that SPI is one of the more important interfaces on the
> BoardBoard. As such, it would be really nice if there was a standard test of
> SPI functionality. It seems many people have struggled to get SPI working on
> the BeagleBoard and not too many have succeeded. A standard prescription would
> be extremely useful.
>
> P.P.S. Is it just me or does the omap_pinmux interface need some refinement.
> Using it has been an exercise in frustration, between extremely sparse
> documentation, quirky behavior (I still haven't figure out how to get gpio_130
> configured.  omap_mux_init_gpio fails with "multiple paths for gpio130" whereas
> omap_mux_init_signal fails to even recognize the signal name), and general
> complexity. The idea behind the interface seems excellent, but it seems it
> hasn't been used enough not to be a complete pain in the ass to figure out and
> use.
>
>
> [1] http://markmail.org/message/2vbfuz7bltvrk6g3#query:beagle%20spi%20zeros+page:1+mid:wduqfhs4ur373ehp+state:results
> [2] http://groups.google.com/group/beagleboard/browse_thread/thread/42988f0e14db0f01/816397901ec999c4?lnk=gst&q=Balister+&pli=1
> [3] http://goldnerlab.physics.umass.edu/git?p=tracker-board.git;a=summary
>
>
>
> diff --git a/arch/arm/mach-omap2/board-omap3beagle.c b/arch/arm/mach-omap2/board-omap3beagle.c
> index 231cb4e..b23c5a5 100644
> --- a/arch/arm/mach-omap2/board-omap3beagle.c
> +++ b/arch/arm/mach-omap2/board-omap3beagle.c
> @@ -12,6 +12,10 @@
>    * published by the Free Software Foundation.
>    */
>
> +//#define BEAGLE_GPIO_SPI
> +
> +
> +
>   #include<linux/kernel.h>
>   #include<linux/init.h>
>   #include<linux/platform_device.h>
> @@ -28,6 +32,7 @@
>   #include<linux/mtd/partitions.h>
>   #include<linux/mtd/nand.h>
>
> +#include<linux/spi/spi.h>
>   #include<linux/regulator/machine.h>
>   #include<linux/i2c/twl.h>
>
> @@ -372,6 +377,159 @@ static struct platform_device *omap3_beagle_devices[] __initdata = {
>   	&keys_gpio,
>   };
>
> +#ifndef BEAGLE_GPIO_SPI
> +
> +static void __init omap3_beagle_config_mcspi3_mux(void)
> +{
> +	omap_mux_init_signal("sdmmc2_clk.mcspi3_clk", OMAP_PIN_OUTPUT);
> +	omap_mux_init_signal("sdmmc2_dat3.mcspi3_cs0", OMAP_PIN_OUTPUT);
> +	omap_mux_init_signal("sdmmc2_dat2.mcspi3_cs1", OMAP_PIN_OUTPUT);
> +	omap_mux_init_signal("sdmmc2_cmd.mcspi3_simo", OMAP_PIN_OUTPUT);
> +	omap_mux_init_signal("sdmmc2_dat0.mcspi3_somi", OMAP_PIN_INPUT_PULLUP);
> +}
> +
> +static void __init omap3_beagle_config_mcspi4_mux(void)
> +{
> +	omap_mux_init_signal("mcbsp1_clkr.mcspi4_clk", OMAP_PIN_OUTPUT);
> +	omap_mux_init_signal("mcbsp1_fsx.mcspi4_cs0", OMAP_PIN_OUTPUT);
> +	omap_mux_init_signal("mcbsp1_dx.mcspi4_simo", OMAP_PIN_OUTPUT);
> +	omap_mux_init_signal("mcbsp1_dr.mcspi4_somi", OMAP_PIN_INPUT_PULLUP);
> +}
> +
> +static struct spi_board_info beagle_mcspi_board_info[] = {
> +	// spi 3.0
> +	{
> +		.modalias	= "spidev",
> +		.max_speed_hz	= 48000000, //48 Mbps
> +		.bus_num	= 3,
> +		.chip_select	= 0,	
> +		.mode = SPI_MODE_1,
> +	},
> +
> +	// spi 3.1
> +	{
> +		.modalias	= "spidev",
> +		.max_speed_hz	= 48000000, //48 Mbps
> +		.bus_num	= 3,
> +		.chip_select	= 1,	
> +		.mode = SPI_MODE_1,
> +	},
> +
> +	// spi 4.0
> +	{
> +		.modalias	= "spidev",
> +		.max_speed_hz	= 48000000, //48 Mbps
> +		.bus_num	= 4,
> +		.chip_select	= 0,	
> +		.mode = SPI_MODE_1,
> +	},
> +};
> +
> +#else /* BEAGLE_GPIO_SPI */
> +#include<linux/spi/spi_gpio.h>
> +
> +#define SPI3_CLK 130
> +#define SPI3_SOMI 132
> +#define SPI3_SIMO 131
> +#define SPI3_CS0 135
> +#define SPI3_CS1 134
> +
> +#define SPI4_CLK 156
> +#define SPI4_SOMI 159
> +#define SPI4_SIMO 158
> +#define SPI4_CS0 161
> +
> +#define GPIO_SPI_PIN(pin, dir, name)  \
> +	omap_mux_init_gpio(pin, OMAP_PIN_##dir); \
> +	gpio_request(pin, name); \
> +	gpio_export(pin, true);
> +
> +static void __init omap3_beagle_config_gpio_spi3_mux(void)
> +{
> +	GPIO_SPI_PIN(SPI3_CLK, OUTPUT, "spi3_clk");
> +	GPIO_SPI_PIN(SPI3_SIMO, OUTPUT, "spi3_simo");
> +	GPIO_SPI_PIN(SPI3_SOMI, INPUT, "spi3_somi");
> +	GPIO_SPI_PIN(SPI3_CS0, OUTPUT, "spi3_cs0");
> +	GPIO_SPI_PIN(SPI3_CS1, OUTPUT, "spi3_cs1");
> +}
> +
> +static void __init omap3_beagle_config_gpio_spi4_mux(void)
> +{
> +	GPIO_SPI_PIN(SPI4_CLK, OUTPUT, "spi4_clk");
> +	GPIO_SPI_PIN(SPI4_SIMO, OUTPUT, "spi4_simo");
> +	GPIO_SPI_PIN(SPI4_SOMI, INPUT, "spi4_somi");
> +	GPIO_SPI_PIN(SPI4_CS0, OUTPUT, "spi4_cs0");
> +}
> +
> +static struct spi_gpio_platform_data beagle_gpio_spi_platform_data[] = {
> +	// spi 3
> +	{
> +		.sck = SPI3_CLK,
> +		.miso = SPI3_SOMI,
> +		.mosi = SPI3_SIMO,
> +		.num_chipselect = 2,
> +	},
> +
> +	// spi 4
> +	{
> +		.sck = SPI4_CLK,
> +		.miso = SPI4_SOMI,
> +		.mosi = SPI4_SIMO,
> +		.num_chipselect = 1,
> +	},
> +};
> +
> +static struct platform_device beagle_gpio_spi_platform_device[] = {
> +	// spi .
> +	{
> +		.name		= "spi_gpio",
> +		.id		= 3,
> +		.dev		= {
> +			.platform_data =&beagle_gpio_spi_platform_data[0],
> +		},
> +	},
> +
> +	// spi 4
> +	{
> +		.name		= "spi_gpio",
> +		.id		= 4,
> +		.dev		= {
> +			.platform_data =&beagle_gpio_spi_platform_data[1],
> +		},
> +	},
> +};
> +
> +static struct spi_board_info beagle_gpio_spi_board_info[] = {
> +	// spi 3.0
> +	{
> +		.modalias	= "spidev",
> +		.max_speed_hz	= 48000000, //48 Mbps
> +		.bus_num	= 3,
> +		.mode = SPI_MODE_1,
> +		.controller_data = (void *) SPI3_CS0,
> +	},
> +
> +	// spi 3.1
> +	{
> +		.modalias	= "spidev",
> +		.max_speed_hz	= 48000000, //48 Mbps
> +		.bus_num	= 3,
> +		.mode = SPI_MODE_1,
> +		.controller_data = (void *) SPI3_CS1,
> +	},
> +
> +	// spi 4.0
> +	{
> +		.modalias	= "spidev",
> +		.max_speed_hz	= 48000000, //48 Mbps
> +		.bus_num	= 4,
> +		.mode = SPI_MODE_1,
> +		.controller_data = (void *) SPI4_CS0,
> +	},
> +};
> +
> +#endif /* BEAGLE_GPIO_SPI */
> +
>   static void __init omap3beagle_flash_init(void)
>   {
>   	u8 cs = 0;
> @@ -432,12 +590,30 @@ static struct omap_board_mux board_mux[] __initdata = {
>
>   static void __init omap3_beagle_init(void)
>   {
> +	int i;
> +
>   	omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
>   	omap3_beagle_i2c_init();
>   	platform_add_devices(omap3_beagle_devices,
>   			ARRAY_SIZE(omap3_beagle_devices));
>   	omap_serial_init();
>
> +#ifndef BEAGLE_GPIO_SPI
> +	printk(KERN_ERR "Using McSPI for SPI\n");
> +	omap3_beagle_config_mcspi3_mux();
> +	omap3_beagle_config_mcspi4_mux();
> +	spi_register_board_info(beagle_mcspi_board_info,
> +			ARRAY_SIZE(beagle_mcspi_board_info));
> +#else
> +	printk(KERN_ERR "Using GPIO for SPI\n");
> +	omap3_beagle_config_gpio_spi3_mux();
> +	omap3_beagle_config_gpio_spi4_mux();
> +	for (i=0; i<3; i++)
> +		platform_device_register(&beagle_gpio_spi_platform_device[i]);
> +	spi_register_board_info(beagle_gpio_spi_board_info,
> +			ARRAY_SIZE(beagle_gpio_spi_board_info));
> +#endif
> +
>   	omap_mux_init_gpio(170, OMAP_PIN_INPUT);
>   	gpio_request(170, "DVI_nPD");
>   	/* REVISIT leave DVI powered down until it's needed ... */
> @@ -458,6 +634,7 @@ static void __init omap3_beagle_map_io(void)
>   	omap2_map_common_io();
>   }
>
> +
>   MACHINE_START(OMAP3_BEAGLE, "OMAP3 Beagle Board")
>   	/* Maintainer: Syed Mohammed Khasim - http://beagleboard.org */
>   	.phys_io	= 0x48000000,
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: SPI troubles

[Ned Forrester]

On 03/14/2010 10:44 PM, Ben Gamari wrote:
> 
> When measuring the SIMO signal on the expansion connector with my daughterboard
> connected, I noticed that the daughterboard's level shifter appeared to be
> driving the signal higher than it should, to ~2.9 Volts. I then checked the
> 1.8V rail voltage and found that it too was higher than expected, again at 2.9
> volts. When I unplug the daughterboard, the 1.8V rail voltage returns to its
> expected value.
> 
> I'm both perplexed and concerned with this behavior. I completely fail to
> see how my board is raising the voltage on the 1.8V rail (schematic available
> at [3]).  While the BeagleBoard seems quite stable, I'm very concerned that
> perhaps the daughterboard over-drove the SIMO ball and burned out some subset
> of the OMAP.  Regardless, as mentioned earlier, I have verified the
> functionality of the same ball as a GPIO input. Thus, I am thoroughly confused.
> Is it possible that the ball's GPIO receiver could remain functional while the
> McSPI receiver is burned out?
>
> [3] http://goldnerlab.physics.umass.edu/git?p=tracker-board.git;a=summary

I'd be happy to check your circuit for you, if it were posted in a more
widely used format.  How about a PDF of the schematic.

-- 
Ned Forrester                                       nforrester-/d+BM93fTQY@public.gmane.org
Oceanographic Systems Lab                                  508-289-2226
Applied Ocean Physics and Engineering Dept.
Woods Hole Oceanographic Institution          Woods Hole, MA 02543, USA
http://www.whoi.edu/
http://www.whoi.edu/sbl/liteSite.do?litesiteid=7212
http://www.whoi.edu/hpb/Site.do?id=1532
http://www.whoi.edu/page.do?pid=10079


------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev

Re: [spi-devel-general] SPI troubles

[Ben Gamari]

Thanks for your reply!

On Mon, 15 Mar 2010 11:55:56 +0900, jassi brar <jassisinghbrar@gmail.com> wrote:
> a) You might as well want to verify your SPIDEV setup by using the same pins
> in GPIO mode and controlling them by gpio-bitbanging i/f  ... first on both
> boards and then on either, to more accurately diagnose the problem). 

I have already attempted this, unfortunately. As I pointed out in my first
email, I have failed to get gpio-spi to do anything useful. I'm currently
struggling even to get it to output data, much less read.

> b) Maybe line-strength settings should be checked, if available, of the
> relevant pins?

Please clarify? According to my scope, the signals are picture-perfect. Any
further ideas you might have would be great appreciated. Thanks again,

- Ben

Re: [spi-devel-general] SPI troubles

[Ben Gamari]

On Mon, 15 Mar 2010 10:38:38 -0400, Ned Forrester <nforrester@whoi.edu> wrote:
> I'd be happy to check your circuit for you, if it were posted in a more
> widely used format.  How about a PDF of the schematic.
> 
Certainly, it's a available at http://goldnerlab.physics.umass.edu/~bgamari/schematic.png.

- Ben

Re: SPI troubles

[Ben Gamari]

On Mon, 15 Mar 2010 08:25:09 -0400, Philip Balister <philip@balister.org> wrote:
> For some reason you need to set the clock pin as an input. Here is the 
> config for mcspi1 that is working for me:
> 
> MUX_VAL(CP(MCSPI1_CLK),         (IEN  | PTD | DIS | M0)) /*McSPI1_CLK*/\
> 
> (from u-boot)
> 

Are you sure? Is this to fix the clock or does this really affect the MISO
signal? I have no problems with my clock at the moment. Everything appears to
work except for MISO. 

Cheers,

- Ben

Re: SPI troubles

[Tony Lindgren]

* Ben Gamari <bgamari.foss-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> [100314 19:41]:
> 
> P.P.S. Is it just me or does the omap_pinmux interface need some refinement.
> Using it has been an exercise in frustration, between extremely sparse
> documentation, quirky behavior (I still haven't figure out how to get gpio_130
> configured.  omap_mux_init_gpio fails with "multiple paths for gpio130" whereas
> omap_mux_init_signal fails to even recognize the signal name), and general
> complexity. The idea behind the interface seems excellent, but it seems it
> hasn't been used enough not to be a complete pain in the ass to figure out and
> use.

Hopefully incrementally less frustrating now than earlier though :)

So far the new mux code has been tested pretty much only with the
existing mux settings, so I'm sure quite a some quirks still remain.

The problem of omap_mux_init_gpio not recognizing full signal names
is known. At least it correctly gives you warnings and refuses to
do anything. The real fix probably in the long run is to change
everything to use omap_mux_init_signal instead.

But what's the issue of omap_mux_init_signal not recognizing the
signal name? It should be just "mode0_name.desired_mode". Is some
entry maybe missing from mux34xx.c?

Some of the complexity disappears once I get around to converting
the 24xx muxing to the new code so we can get rid of the old code.
Some complexity is caused by the need to support bootloader-only muxing
while still dynamically muxing the GPIO pins for PM idle.

Got some good ideas on how to cut down the complexity further?

Regards,

Tony

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev

Re: [spi-devel-general] SPI troubles

[Ned Forrester]

On 03/15/2010 11:57 AM, Ben Gamari wrote:
> When measuring the SIMO signal on the expansion connector with my daughterboard
> connected, I noticed that the daughterboard's level shifter appeared to be
> driving the signal higher than it should, to ~2.9 Volts. I then checked the
> 1.8V rail voltage and found that it too was higher than expected, again at 2.9
> volts. When I unplug the daughterboard, the 1.8V rail voltage returns to its
> expected value.
>
> On Mon, 15 Mar 2010 10:38:38 -0400, Ned Forrester <nforrester@whoi.edu> wrote:
>> I'd be happy to check your circuit for you, if it were posted in a more
>> widely used format.  How about a PDF of the schematic.
>>
> Certainly, it's a available at http://goldnerlab.physics.umass.edu/~bgamari/schematic.png.

Your problem is likely caused by pulling the THREE STATE pin to 5V.  The
spec sheet is explicit (in the Absolute Maximum ratings on page 2, and
in the functional description on page 12 that this pin should be pulled
to VL, not VCC to enable the outputs.  Likely by pulling it to 5V the
some part of the chip is biased wrong and may cause OVL1 to be pulled
above VL.

I can't exactly explain the symptoms you report above, based on the
mis-connected pin, but most anything could be happening in the MAX3390
once the absolute maximum ratings have been exceeded.  The 10K resistors
on the THREE STATE lines may have saved the circuit from permanent
damage, but they may not save it from improper operation.

Other suggestions, nothing fatal...

1. The pinout of the MAX3390E on the drawing is for the TSSOP package.
Hopefully that is the package you actually used.

2. All uncommitted inputs should be terminated high or low.  This
applies to: LS2 pins 4, 5 and 13; LS3 pin 13 and possibly unused pins on
the A/Ds and D/A.

3. The MAX3390E family has extremely low drive capability and slow
response.  Is this device really fast enough for your intended clock
rates?  Note that the device can only pull down 1ma, and can only pull
up 20ua.  If there are any pull-downs or pull-ups on the BeagleBoard,
the MAX3390E might not be able to drive them.

4. I find it curious that the AVDD to the A/D and D/A is fead through a
1ohm resistor that is paralleled by C11 and C12.  Likely you meant to
tie one side of each of C11 and C12 (the side now connected to C10
positive) to ground.  That connection would make a filter to reduce the
noise on AVDD rather than passing the noise along.

5. Is see on the Maxim site that this series of translators is not
recommended for new design.  Likely the suggested alternatives have much
better specifications.

-- 
Ned Forrester                                       nforrester@whoi.edu
Oceanographic Systems Lab                                  508-289-2226
Applied Ocean Physics and Engineering Dept.
Woods Hole Oceanographic Institution          Woods Hole, MA 02543, USA
http://www.whoi.edu/
http://www.whoi.edu/sbl/liteSite.do?litesiteid=7212
http://www.whoi.edu/hpb/Site.do?id=1532
http://www.whoi.edu/page.do?pid=10079

Re: [spi-devel-general] SPI troubles

[Ben Gamari]

Thank you very much for your response. As you might have gathered, I seem to
have it working but your feedback is really appreciated. I hope to do another
run of these boards with these fixes.

On Mon, 15 Mar 2010 16:57:27 -0400, Ned Forrester <nforrester@whoi.edu> wrote:
> 
> Your problem is likely caused by pulling the THREE STATE pin to 5V.  The
> spec sheet is explicit (in the Absolute Maximum ratings on page 2, and
> in the functional description on page 12 that this pin should be pulled
> to VL, not VCC to enable the outputs.  Likely by pulling it to 5V the
> some part of the chip is biased wrong and may cause OVL1 to be pulled
> above VL.

You are absolutely right. I don't know how I missed that. I just reworked my
existing board and it seems to be fine now. A very good find. Thanks a ton.

> 
> I can't exactly explain the symptoms you report above, based on the
> mis-connected pin, but most anything could be happening in the MAX3390
> once the absolute maximum ratings have been exceeded.  The 10K resistors
> on the THREE STATE lines may have saved the circuit from permanent
> damage, but they may not save it from improper operation.

Well, thankfully at least one of the channels works. Unfortunately, I somehow
managed to replace one of the 10k resistors with a 1 ohm, so it's possible that
one of the level shifters on this board is fried. Naturally, I've been sampling
all of my parts thusfar and only now realized that the MAX1303 is unavailable
through the traditional channels (e.g. Digikey, Newark).

> 
> Other suggestions, nothing fatal...
> 
> 1. The pinout of the MAX3390E on the drawing is for the TSSOP package.
> Hopefully that is the package you actually used.

Yep, it is.

> 
> 2. All uncommitted inputs should be terminated high or low.  This
> applies to: LS2 pins 4, 5 and 13; LS3 pin 13 and possibly unused pins on
> the A/Ds and D/A.
> 
Very good point. I really should be a little more careful about this.

> 3. The MAX3390E family has extremely low drive capability and slow
> response.  Is this device really fast enough for your intended clock
> rates?  Note that the device can only pull down 1ma, and can only pull
> up 20ua.  If there are any pull-downs or pull-ups on the BeagleBoard,
> the MAX3390E might not be able to drive them.

You are right. I had a remarkably difficult time sourcing level shifters for
this project at first because I wasn't intending on getting a PCB made. For
this reason, I standardized on TSSOP packages, which I could easily get DIP
adapters for. I've since realized that getting a PCB made is definitely worth
it.

> 
> 4. I find it curious that the AVDD to the A/D and D/A is fead through a
> 1ohm resistor that is paralleled by C11 and C12.  Likely you meant to
> tie one side of each of C11 and C12 (the side now connected to C10
> positive) to ground.  That connection would make a filter to reduce the
> noise on AVDD rather than passing the noise along.
> 
Ouch, you are definitely right. Screwed that up.

> 5. Is see on the Maxim site that this series of translators is not
> recommended for new design.  Likely the suggested alternatives have much
> better specifications.

Yep, I went with these because they were available in TSSOP.

All things considering, I think it might be time to start off with a clean
slate. This was an interesting first draft, but I think the constraints it was
designed within are largely inapplicable now.

TI has some very nice converters that will operate directly on 1.8V signals,
which would cut the chip count in half. Unfortunately they are in QFN packages,
which seem difficult at best to solder by hand. On the other hand, there are
also many higher-channel count TSSOP parts that look pretty enticing, although
none of them seem to operate at 1.8V.

I was hoping to finish this design up over the Spring break (now), but I guess
our data-taking will just have to wait. Arg.

Thanks a ton for your help. It's far too easy to overlook your own mistakes.

- Ben

Re: [spi-devel-general] SPI troubles

[Ned Forrester]

On 03/15/2010 09:06 PM, Ben Gamari wrote:
> Thank you very much for your response. As you might have gathered, I seem to
> have it working but your feedback is really appreciated. I hope to do another
> run of these boards with these fixes.
> 
> On Mon, 15 Mar 2010 16:57:27 -0400, Ned Forrester <nforrester@whoi.edu> wrote:
>>
>> Your problem is likely caused by pulling the THREE STATE pin to 5V.  The
>> spec sheet is explicit (in the Absolute Maximum ratings on page 2, and
>> in the functional description on page 12 that this pin should be pulled
>> to VL, not VCC to enable the outputs.  Likely by pulling it to 5V the
>> some part of the chip is biased wrong and may cause OVL1 to be pulled
>> above VL.
> 
> You are absolutely right. I don't know how I missed that. I just reworked my
> existing board and it seems to be fine now. A very good find. Thanks a ton.

Glad I could help.

>> I can't exactly explain the symptoms you report above, based on the
>> mis-connected pin, but most anything could be happening in the MAX3390
>> once the absolute maximum ratings have been exceeded.  The 10K resistors
>> on the THREE STATE lines may have saved the circuit from permanent
>> damage, but they may not save it from improper operation.
> 
> Well, thankfully at least one of the channels works. Unfortunately, I somehow
> managed to replace one of the 10k resistors with a 1 ohm, so it's possible that
> one of the level shifters on this board is fried. Naturally, I've been sampling
> all of my parts thusfar and only now realized that the MAX1303 is unavailable
> through the traditional channels (e.g. Digikey, Newark).

www.findchips.com covers most of the usual US distributors.  It's not
really restricted to chips, any part number works fine.

Maxim encourages direct purchase from their web site, so sometimes that
is the best place to find stock.

There are 41 in stock at Avnet, in the TQFN package.  Not what you would
like to hand solder, but it can be done if the lands on the PCB are
designed to stick out farther than usual, so that you can get the iron
on the land (since you can't reach the pin itself).  A flux pen helps,
such as Kester #951 (but read the Material Safety Data Sheet).

As someone said on the net years ago (and still true, except for things
like ball grid arrays), "They haven't yet invented a surface mount part
that can't be hand soldered with a temperature controlled iron and $2000
worth of optics and lighting."

>> Other suggestions, nothing fatal...
>>
>> 1. The pinout of the MAX3390E on the drawing is for the TSSOP package.
>> Hopefully that is the package you actually used.
> 
> Yep, it is.
> 
>>
>> 2. All uncommitted inputs should be terminated high or low.  This
>> applies to: LS2 pins 4, 5 and 13; LS3 pin 13 and possibly unused pins on
>> the A/Ds and D/A.
>>
> Very good point. I really should be a little more careful about this.
> 
>> 3. The MAX3390E family has extremely low drive capability and slow
>> response.  Is this device really fast enough for your intended clock
>> rates?  Note that the device can only pull down 1ma, and can only pull
>> up 20ua.  If there are any pull-downs or pull-ups on the BeagleBoard,
>> the MAX3390E might not be able to drive them.
> 
> You are right. I had a remarkably difficult time sourcing level shifters for
> this project at first because I wasn't intending on getting a PCB made. For
> this reason, I standardized on TSSOP packages, which I could easily get DIP
> adapters for. I've since realized that getting a PCB made is definitely worth
> it.

I don't have boards hand assembled any more.  The parts are just too
small, and you have to have a really good tech (or be one) to get a job
as clean and reliable as with soldering in a oven.  There are lots of
assembly houses out there.

>> 4. I find it curious that the AVDD to the A/D and D/A is fed through a
>> 1ohm resistor that is paralleled by C11 and C12.  Likely you meant to
>> tie one side of each of C11 and C12 (the side now connected to C10
>> positive) to ground.  That connection would make a filter to reduce the
>> noise on AVDD rather than passing the noise along.
>>
> Ouch, you are definitely right. Screwed that up.
> 
>> 5. I see on the Maxim site that this series of translators is not
>> recommended for new design.  Likely the suggested alternatives have much
>> better specifications.
> 
> Yep, I went with these because they were available in TSSOP.
> 
> All things considering, I think it might be time to start off with a clean
> slate. This was an interesting first draft, but I think the constraints it was
> designed within are largely inapplicable now.
> 
> TI has some very nice converters that will operate directly on 1.8V signals,
> which would cut the chip count in half. Unfortunately they are in QFN packages,
> which seem difficult at best to solder by hand. On the other hand, there are
> also many higher-channel count TSSOP parts that look pretty enticing, although
> none of them seem to operate at 1.8V.

I have been using TI translators recently; that is, when I don't use a
CPLD or FPGA (there's nothing quite like a programmable device when you
think of a better idea).  TI has a line of translators in small
packages. See, for example, 74LVC1T45, a single translator in a 6 pin
SC70 package that you could hand solder.  Wider parts probably make more
sense for your design.

> I was hoping to finish this design up over the Spring break (now), but I guess
> our data-taking will just have to wait. Arg.

Ahh, student budget vs. student labor.  That will change the range of
outside services that you can use.

> Thanks a ton for your help. It's far too easy to overlook your own mistakes.
> 
> - Ben
> 
> 


-- 
Ned Forrester                                       nforrester@whoi.edu
Oceanographic Systems Lab                                  508-289-2226
Applied Ocean Physics and Engineering Dept.
Woods Hole Oceanographic Institution          Woods Hole, MA 02543, USA
http://www.whoi.edu/
http://www.whoi.edu/sbl/liteSite.do?litesiteid=7212
http://www.whoi.edu/hpb/Site.do?id=1532
http://www.whoi.edu/page.do?pid=10079