MCSPI3 working, both ways

I have spidev_test reading data sent from the port now. Steve sent me
a patch for u-boot to set up the pinmux in u-boot. I removed the
pinmux code from Linux and I could read data from the SPI port:

http://www.flickr.com/photos/32615155@N00/3291304854/

I'm attaching the patch against OE. The u-boot patch is from Steve.

I compile spidev_test.c with this command:

/home/balister/oe/tmp/cross/armv7a/bin/arm-angstrom-linux-gnueabi-gcc
-o spidev_test spidev_test.c

Adjust for the path to your cross compiler. I am using the one built by OE.

Philip

0001-Changes-to-make-MCSPI3-work-on-the-Beagle-Board-expa.patch (14.6 KB)

Hello,
It is so good to see someone succeed in receiving data!!
Could we have Steve's u-boot patch to try?

thanks,
Yuchih

Hello,
It is so good to see someone succeed in receiving data!!
Could we have Steve's u-boot patch to try?

It is the the patch against the OE mete-data :slight_smile:

I've attached is separately.

Philip

crofton.patch (964 Bytes)

Ha, i didn't see the u-boot patch is already in the first patch.
Philip, so only u-boot pinmux setup instead of the one in kernel makes
the RX read available?

I have patched u-boot, but still got Rx all zeros.
My u-boot source is from http://beagleboard.googlecode.com/files/u-boot_beagle_revb.tar.gz
Kernel source is from linux omap git server.
Maybe i have to try the OE, does anyone also succeed?

yuchih

Ha, i didn't see the u-boot patch is already in the first patch.
Philip, so only u-boot pinmux setup instead of the one in kernel makes
the RX read available?

I won't say that, it would be worth trying to setup only the pins that
are setup in the u-boot patch, in the kernel.

I have patched u-boot, but still got Rx all zeros.
My u-boot source is from http://beagleboard.googlecode.com/files/u-boot_beagle_revb.tar.gz
Kernel source is from linux omap git server.
Maybe i have to try the OE, does anyone also succeed?

OE does make life easier, once you get the hang of it :slight_smile:

Philip

Hello Philip,

I have spidev_test reading data sent from the port now. Steve sent me
a patch for u-boot to set up the pinmux in u-boot. I removed the
pinmux code from Linux and I could read data from the SPI port:

Congrats.

http://www.flickr.com/photos/32615155@N00/3291304854/

Nice setup.

Maybe I should exchange one cat for a scope.

It helps debugging in a better way.

Regards,

Hi Philip,

Could you briefly explain your setup and Mux settings below, are these
for the slave mode.

++ MUX_VAL(CP(MMC2_CLK), (IEN | PTU | DIS | M1)) /*MCSPI3_CLK*/\
++ MUX_VAL(CP(MMC2_CMD), (IEN | PTU | DIS | M1)) /*MCSPI3_SIMO*/\
++ MUX_VAL(CP(MMC2_DAT0), (IEN | PTU | EN | M1)) /*MCSPI3_SOMI*/\

I am trying to test data transfers using SPI2 on two OMAP3430SDP
boards. One SPI2 is configured as master and the other as slave. I am
also seeing similar problem where Slave writes but the master is
unable to read proper data. I am trying to figure out if your settings
will help.

Thanks
Hemanth

Hi Philip,

Could you briefly explain your setup and Mux settings below, are these
for the slave mode.

++ MUX_VAL(CP(MMC2_CLK), (IEN | PTU | DIS | M1)) /*MCSPI3_CLK*/\
++ MUX_VAL(CP(MMC2_CMD), (IEN | PTU | DIS | M1)) /*MCSPI3_SIMO*/\
++ MUX_VAL(CP(MMC2_DAT0), (IEN | PTU | EN | M1)) /*MCSPI3_SOMI*/\

I am trying to test data transfers using SPI2 on two OMAP3430SDP
boards. One SPI2 is configured as master and the other as slave. I am
also seeing similar problem where Slave writes but the master is
unable to read proper data. I am trying to figure out if your settings
will help.

This code sets up the pinmux in u-boot. I'm not sure where the docs
are for this. Hopefully, someone who knows how to set up the pinmux in
u-boot will speak up.

Philip

From: beagleboard@googlegroups.com
[mailto:beagleboard@googlegroups.com] On Behalf Of
hemanth_venkatesh@yahoo.com
Sent: Monday, March 02, 2009 12:38 AM
To: Beagle Board
Subject: [beagleboard] Re: MCSPI3 working, both ways

Hi Philip,

Could you briefly explain your setup and Mux settings below, are these
for the slave mode.

++ MUX_VAL(CP(MMC2_CLK), (IEN | PTU | DIS | M1))

/*MCSPI3_CLK*/\

++ MUX_VAL(CP(MMC2_CMD), (IEN | PTU | DIS | M1))

/*MCSPI3_SIMO*/\

++ MUX_VAL(CP(MMC2_DAT0), (IEN | PTU | EN | M1))
/*MCSPI3_SOMI*/\

I am trying to test data transfers using SPI2 on two OMAP3430SDP
boards. One SPI2 is configured as master and the other as slave. I am
also seeing similar problem where Slave writes but the master is
unable to read proper data. I am trying to figure out if your settings
will help.

I don't believe the Linux SPI driver supports slave mode.

Thanks
Hemanth

> I have spidev_test reading data sent from the port now. Steve sent me
> a patch for u-boot to set up the pinmux in u-boot. I removed the
> pinmux code from Linux and I could read data from the SPI port:
>
> http://www.flickr.com/photos/32615155@N00/3291304854/
>
> I'm attaching the patch against OE. The u-boot patch is from Steve.
>
> I compile spidev_test.c with this command:
>
> /home/balister/oe/tmp/cross/armv7a/bin/arm-angstrom-linux-gnueabi-gcc
> -o spidev_test spidev_test.c
>
> Adjust for the path to your cross compiler. I am using the one built by

OE.

Yes currently it doesnot. I am trying to add slave support but am
facing the above problem. I am able to get Master write/Slave read
working though.

There is a function in <u-boot>/board/omap3/beagle/beagle.c called
set_muxconf_regs(). It "calls" what really is a define that is set up
in <u-boot>/include/asm-arm/arch-omap3/mux.h, called MUX_DEFAULT_ES2
().

If you want you can change the define for MUX_DEFAULT_ES2 or copy it,
rename it and then "call" your new define from set_muxconf_regs().

The muxing define itself is easy enough to figure out from the
comments right above...

tim

The u-boot pin muxing to get spidev working is:

MUX_VAL(CP(MMC2_CLK), (IEN | PTU | DIS | M1)) /*MCSPI3_CLK*/\
MUX_VAL(CP(MMC2_CMD), (IEN | PTU | DIS | M1)) /*MCSPI3_SIMO*/\
MUX_VAL(CP(MMC2_DAT0), (IEN | PTU | EN | M1)) /*MCSPI3_SOMI*/\

I'm running out of options to try on this. So far I've:

Using (0001-Changes-to-make-MCSPI3-work-on-the-Beagle-Board-
expa.patch) patched against openembedded (modified patch directories
to /recipes/ instead of /packages/)

Linux
cleaned bitbake -c clean -b /openembedded/recipes/linux/linux-
omap_2.6.28.bb
rebuilt bitbake -b linux-omap_2.6.28.bb
verified that a message appeared during build "Applying patch 'spi-
test.patch'"

U-Boot
cleaned bitbake -c clean -b /openembedded/recipes/u-boot/u-
boot_git.bb
rebuilt bitbake -b /openembedded/recipes/u-boot/u-boot_git.bb
verified that a message appeared during build "Applying patch
'crofton.patch'"

transferred over the newly built u-boot.bin and uImage to my SD card
from /tmp/deploy/glibc/images/beagleboard.

When the system boots up I can see two registered spi devices under /
dev

spidev3.0
spidev4.0

spidev_test
Cross compiled on development machine and transferred to /home/root on
the beagle. I've been running spidev_test like this:

spidev_test -D /dev/spidev3.0 -s 20000

this produces no errors just something like:

root@beagleboard:~# spidev_test /dev/spidev3.0 -s 2000000 -H -O -b
16
spi mode:
3
bits per word:
16
max speed: 2000000 Hz (2000
KHz)

00 00 00 00 00
00
00 00 00 00 00
00
00 00 00 00 00
00
00 00 00 00 00
00
00 00 00 00 00
00
00 00 00 00 00
00
00 00

Nothing changes on pins 19 (SIMO) or 21 (CLK) when I hook up my scope
and run spidev_test on /dev/spidev3.0, the lines remain pulled high.

Is there a step in here I'm missing? Am I running spidev_test
correctly?

Thanks,

Andrew

I'm running out of options to try on this. So far I've:

Using (0001-Changes-to-make-MCSPI3-work-on-the-Beagle-Board-
expa.patch) patched against openembedded (modified patch directories
to /recipes/ instead of /packages/)

Linux
cleaned bitbake -c clean -b /openembedded/recipes/linux/linux-
omap_2.6.28.bb
rebuilt bitbake -b linux-omap_2.6.28.bb
verified that a message appeared during build "Applying patch 'spi-
test.patch'"

U-Boot
cleaned bitbake -c clean -b /openembedded/recipes/u-boot/u-
boot_git.bb
rebuilt bitbake -b /openembedded/recipes/u-boot/u-boot_git.bb
verified that a message appeared during build "Applying patch
'crofton.patch'"

transferred over the newly built u-boot.bin and uImage to my SD card
from /tmp/deploy/glibc/images/beagleboard.

When the system boots up I can see two registered spi devices under /
dev

spidev3.0
spidev4.0

spidev_test
Cross compiled on development machine and transferred to /home/root on
the beagle. I've been running spidev_test like this:

spidev_test -D /dev/spidev3.0 -s 20000

this produces no errors just something like:

root@beagleboard:~# spidev_test /dev/spidev3.0 -s 2000000 -H -O -b
16
spi mode:
3
bits per word:
16
max speed: 2000000 Hz (2000
KHz)

00 00 00 00 00
00
00 00 00 00 00
00
00 00 00 00 00
00
00 00 00 00 00
00
00 00 00 00 00
00
00 00 00 00 00
00
00 00

Nothing changes on pins 19 (SIMO) or 21 (CLK) when I hook up my scope
and run spidev_test on /dev/spidev3.0, the lines remain pulled high.

Is there a step in here I'm missing? Am I running spidev_test
correctly?

Have you connected the data in to data out pins so you can loop back
test the driver?

Philip

Hi Philip thanks for your reply. I have not connected the SIMO line
back onto SOMI on the expansion header, I'll give that a shot today
and see if I can read any data coming out. What really worries me is
that I cannot see any change on the SIMO line on the scope so I have a
sneaking suspicion that nothing is getting out to the pin.

Andrew

Hi Philip thanks for your reply. I have not connected the SIMO line
back onto SOMI on the expansion header, I'll give that a shot today
and see if I can read any data coming out. What really worries me is
that I cannot see any change on the SIMO line on the scope so I have a
sneaking suspicion that nothing is getting out to the pin.

Yeah, that bother me also. Go over the mux stuff really carefully.
Here is a photo of it working for me:

Imgur

I have a rev A board, not sure if that makes any difference.

Philip

Hi Andrew,

I can't remember if you previously wrote which board type you have (B or C)?

In case of Rev C take care - The McBSP3 pins (RX, TX and CLK) were changed
compared to Rev B.
This in order to allow access to the PWM signals on the expansion connector
as well..

Instead of muxing the balls AF6, AE6 and AF5 you therefore need to mux the
balls AB26, AB25 and AA25...

With this addition/change to Philips original patch (to u-boot AFAIR?) I
guess it will work for you...

Best regards - Good luck
  Søren

Hmm - Apparently I'm a bit too much into Easter-vacation-mode :slight_smile:

Sorry for mixing McBSP3 with McSPI3...

AFAIK there are no changes to the McSPI3 connections...

Best regards and Sorry again
  Søren

Hi Philip thanks for your reply. I have not connected the SIMO line
back onto SOMI on the expansion header, I'll give that a shot today
and see if I can read any data coming out. What really worries me is
that I cannot see any change on the SIMO line on the scope so I have a
sneaking suspicion that nothing is getting out to the pin.

Yeah, that bother me also. Go over the mux stuff really carefully.
Here is a photo of it working for me:

http://www.flickr.com/photos/32615155@N00/3291304854/

I have a rev A board, not sure if that makes any difference.

Philip

Hi Andrew,

I can't remember if you previously wrote which board type you have (B or C)?

In case of Rev C take care - The McBSP3 pins (RX, TX and CLK) were changed
compared to Rev B.
This in order to allow access to the PWM signals on the expansion connector
as well..

Instead of muxing the balls AF6, AE6 and AF5 you therefore need to mux the
balls AB26, AB25 and AA25...

With this addition/change to Philips original patch (to u-boot AFAIR?) I
guess it will work for you...

Best regards - Good luck
  Søren

I have access to three boards, two rev B6's and one rev C2. The two
I've been testing with are the B6's. I'm running a few tests right
now, hopefully I'll have some results to post soon. Thanks!

I recently went through the exercise of getting the McSPI4 and McSPI3 to work
and I found a few odd things that might be useful.

The McSPI's seem to have an odd quirk in that it requires the input driver to
be enabled for the clock line. I came to this conclusion after checking the
pin mux and using the sys test features of the McSPI to verify the signals
were indeed being routed to the McSPI block.

Running the test program and with a scope, I was able to verify McSPI
clock out and MOSI. Using the sys test features (see TRM), I was able to
read the state of the MISO line after tying it high or low through a resistor
to either 18V or ground. My understanding of the sys test functionality is
that the read back of the lines is totally independent from the GPIO input
stuff.

What made the loop back work for me was enabling the input receivers
on the McSPI clock line. It is behaving as if the input shift register for the
McSPI is gettng its clock from outside of the block (but still inside the
chip). Prehaps this was a designed in feature to allow a seperate input clock
that got removed at the last minute on the OMAP? Just a guess as I was
not able to find an errata or note about this requirement. The McSPI is
definitely more complex then the original SPI stuff where MISO and MOSI are
ends of the same shift register so there is only one clock.

Hope this is somewhat helpful as I do not use OE.