MCSPI TX works fine, but RX all zeros

890 views
Skip to first unread message

Kevin Uhlir

unread,
Dec 14, 2008, 3:45:43 AM12/14/08
to beagl...@googlegroups.com
I've been struggling with a problem with MCSPI3 and MCSPI4 on the expansion
connector. I've enabled SPI3 and SPI4 and I'm testing with spidev. I've got
the PADCONFs set correctly -- (I've verified this more times than you can
imagine).

The problem is all SPI RX data is zero. TX Data goes out just fine, appears
out the SIMO line, along with SCLK and CS0. I've verified that the data is
getting to the expansion connector.

I've also configured the SOMI pad to have a pullup, which I verified on the
pin itself, which should produce all ones for RX data, but I still get
zeros.

I've also configured the SOMI pin as gpio, and verified that the data is
getting through to the cpu using /sys/class/gpio for testing. Both 1's and
0's work fine on the pin when being used as gpio, but not SPI.

I'm beginning to suspect that there is something wrong with the SPI
controller, but I doubt it.

I've also added some debugging code to drivers/spi/omap2_mcspi.c to print
out the data as it goes in an out of the driver. Here too, RX data is all
zeros. One place I did this is inside omap2_mcspi_txrx_pio, which is used
when the number of bytes to transfer is less than 8. It made it easier to
verify each byte going in and out.

I'm using linux-omap_git package for my kernel,
(Angstrom/2.6.27+2.6.28-rc6+r2+git). I know this is a few weeks old, but
I've looked through the commits and I don't see anything that would address
this.

Anyone have any insight on this issue?

Kevin

Hunyue Yau

unread,
Dec 14, 2008, 4:10:35 AM12/14/08
to beagl...@googlegroups.com
Have you checked if there are other pins/balls for the McSPI RX line and made
sure they are configured in some mode other than for the McSPI function?
Making them all the other possible McSPI3 and McSPI4 RX pins GPIO inputs
should be a safe thing.

I ran into a similar issue on the UART where RX didn't work due to U-boot
setting up another ball as the RX and I enabled the expansion connector
connected ball also as RX. I am guessing that caused an internal conflict
since there are 2 sources driving the same line. I fixed this by putting the
other ball in GPIO mode.
--
Hunyue Yau
http://www.hy-research.com/

Kevin Uhlir

unread,
Dec 14, 2008, 4:17:15 AM12/14/08
to beagl...@googlegroups.com
Yes, I thought of that. I've verified the contents of all the other PADCONF
registers that reference MCSPI3 or MCSPI4, and none of them are in a mode
which enables it on any pin/ball except for the one I'm using.

Kevin

Azbell, Brandon

unread,
Dec 14, 2008, 11:38:52 AM12/14/08
to beagl...@googlegroups.com
Is the INPUTENABLE bit in the CONTROL_PADCONF_* register set to logic 1? Just double checking. It is one thing to have the MUXMODE setup for the MCSPI3 or MCSPI4, but you need to ensure the logic around the I/O pad is configured appropriately.


Brandon Azbell

shankar

unread,
Dec 14, 2008, 1:38:15 PM12/14/08
to beagl...@googlegroups.com
Hi ,
What kind of peripheral you are testing with McSPI ?
The fundamental concept of SPI hardware is that it will have single
shift register for both Rx and Tx .

Assuming the use case of 8 bit configuration of SPI, with full duplex
communication, when you write 8 bit data to Transmit Hold register ,
CLK becomes active for 8 cycles (*only*), in which 8 bit data from
master is sent to slave and 8 bit data is received from slave. Hence
during this time if slave doesn't have any response , your Receive Hold
Register(RHR) will be ZERO .

Hence if you have request response transaction of x bits word size, when
you send REQ1 of x bits size, then response RES1 from slave will be
available after xth cycle, hence while sending REQ2 , your RHR will
contain RES1 and so on .. (*assuming no reset happens between REQ1 and
REQ2 .)

CS THR RHR
cycle 1 req1 0
cycle 2 req2 res1
cycle 3 req3 res2
cycle n req n res n-1

and so on

Regards,
Shankar

Kevin Uhlir

unread,
Dec 14, 2008, 1:59:58 PM12/14/08
to beagl...@googlegroups.com
At this point, for testing, I've disconnected the peripheral, and hard
wired the SOMI input to "1". So, I should receive all '1's at all times.

I've also tried a loop back -- connecting SOMI to MOSI, while I can see the
correct data at the pin on the scope and the logic analyzer, all RX data is
still zero when the driver reads the RX register.

Kevin

> -----Original Message-----
> From: beagl...@googlegroups.com
> [mailto:beagl...@googlegroups.com] On Behalf Of shankar
> Sent: Sunday, December 14, 2008 12:38 PM
> To: beagl...@googlegroups.com
> Subject: [beagleboard] Re: MCSPI TX works fine, but RX all zeros
>
>

Kevin Uhlir

unread,
Dec 14, 2008, 2:12:58 PM12/14/08
to beagl...@googlegroups.com
Yes, the PADDCONF register is correct. When I look at the PADCONF register
directly, it is set to 0x119. Unless I'm mistaken this means input enable,
pull up, pull enable, and mode 1. Currently I'm testing with MCSPI3 on the
expansion connector, so MCSPI3_SOMI is configured with the PADCONF register
at 0x4800215c. I've also tried it when its set to 0x101, which just
eliminates the pull-up. I appreciate the suggestions, and welcome anyone
double checking this setting.

FYI, I've tried the same pin, configured as gpio_132, PADCONF setting 0x104.
In this mode, when I export gpio_132, set its direction, and view its value,
it follows the hardware signal level correctly -- 0 when its pulled down, 1
when its pulled up. So the pin itself works.

Hunyue Yau

unread,
Dec 14, 2008, 2:48:31 PM12/14/08
to beagl...@googlegroups.com
On 12/14/2008 11:12 am, Kevin Uhlir wrote:
> Yes, the PADDCONF register is correct. When I look at the PADCONF register
> directly, it is set to 0x119. Unless I'm mistaken this means input enable,
> pull up, pull enable, and mode 1. Currently I'm testing with MCSPI3 on the
> expansion connector, so MCSPI3_SOMI is configured with the PADCONF register
> at 0x4800215c. I've also tried it when its set to 0x101, which just
> eliminates the pull-up. I appreciate the suggestions, and welcome anyone
> double checking this setting.
>
> FYI, I've tried the same pin, configured as gpio_132, PADCONF setting
> 0x104. In this mode, when I export gpio_132, set its direction, and view
> its value, it follows the hardware signal level correctly -- 0 when its
> pulled down, 1 when its pulled up. So the pin itself works.
>
> Kevin

What about the McSPI module itself? Looking at the TRM, there is a TX only
mode. Also, does the OMAP side generate clocks when you are attempting to
receive? (Assuming the OMAP is the single master). If clocks isn't toggling,
you won't receive anything useful.

Another thing to check is the MCSPI_SYST register for the channel in use. It
can change the I/O direction of the SOMI/SIMO lines. Another one to check is
the MCsPI_CHxCONF which can force a single wire mode (xmit/rcvd on the same
pin).

Kevin Uhlir

unread,
Dec 14, 2008, 6:00:15 PM12/14/08
to beagl...@googlegroups.com
I put some more debug code in the driver, and I see the TRM bits are
correct. The SCLK, MOSI, and CS0 are all working fine. I see the clock, I
see CS operating, I see MOSI changing according to the data sent, in sync
with the clock. I just tried SYST setting some values in, but it didn't
fix the problem. Also, the documentation says SYST is only used in system
test mode, which is not enabled.

I decided to dump all the registers in the driver, just before the transfer
is starts:

SYSCONFIG (d80b8010)=00000001 AUTOIDLE

SYSSTATUS (d80b8014)=00000001 RESETDONE

IRQSTATUS (d80b8018)=00000001 TX0_EMPTY

IRQENABLE (d80b801c)=00000000 no IRQ's enabled

WAKEUPENABLE (d80b8020)=00000000 no Wakups enabled

SYST (d80b8024)=00000000 nothing being tested

MODULCTRL (d80b8028)=00000001 SINGLE CHANNEL MODE, MASTER, not SYSTEMTEST

CHCONF (d80b802c)=001103e0 PHA=0, POL=0, CLKD=0x8, EPOL=1,
WL=0x7, TRM=0 (tx+rx mode), DMAW=0, DMAR=0,
DPE0=1 (do not transmit on somi)
DPE1=0 (transmit on simo)
IS=0 (receive on somi)
TURBO=0
FORCE=1 (enable CS0)
SPIENSLV=0 (not used in mastermode)
SBE=0 no start bit
SBPOL=0 start bit polarity =0
TCS=0 cs toggle to clock time
FFEW=0 fifo not enabled
FFER=0 fifo not enabled
CLKG=clock divider granulatity power of 2

CHSTAT (d80b8030)=00000002 TXS -- tx empty

CHCTRL (d80b8034)=00000001 Channel Enabled, EXTCLOCK=0

Everything looks good to me, maybe I misinterpreted something?.

I also tried disabling autoidle, but that didn't help either.

I also made sure that mcspi_ick and mcspi_fck are enabled as well, both by
calling clk_enable in the driver (which wasn't ever in there before), and by
examining the clock config registers.

Kevin

Kevin Uhlir

unread,
Dec 14, 2008, 6:18:46 PM12/14/08
to beagl...@googlegroups.com
I was mistaken about clk_enable not being in the driver, it is in there.
But my problem persists. Rx is all zeros.

Kevin Uhlir

unread,
Dec 16, 2008, 1:59:31 PM12/16/08
to beagl...@googlegroups.com
Thanks for all who have tried to help on this. Its still not working.

In the mean time, I've coded up a simple bit bang spi routine, set the
padconf registers to mux the mcspi3(mode 1) pins to gpio(mode 4), and now I
can receive data through the bit-bang routine. This proves the
hardware/wiring/traces and everything else is correct. Since I can set
padconf to gpio/mode4 and input enable, as appropriate, it proves I'm
setting the right registers. This is only a temporary work around, so I can
continue, while looking for the real solution.

Unless there is something I'm overlooking, I don't believe the mcspi module
is working for receiving data. Has anyone else had success using mcspi3
and/or mcspi4?

Gražvydas

unread,
Dec 16, 2008, 11:59:57 AM12/16/08
to Beagle Board
I've seen somewhat similar problem on pandora board, but there only
first byte was trashed. It appeared to be a problem in the driver, you
can try this patch:
http://marc.info/?l=linux-omap&m=122565580616920&w=2

I doubt it will fix this tough, your problem looks different.

Philip Balister

unread,
Jan 15, 2009, 4:04:09 PM1/15/09
to beagl...@googlegroups.com
This is a great thread, I need to do something very similar. Is the
code you guys are talking about available anywhere? At least the bits
to laod the mcspi driver and setup the pin mux?

This would save me loads of time!

Philip
Message has been deleted
Message has been deleted

Yuchih

unread,
Jan 22, 2009, 9:26:40 PM1/22/09
to Beagle Board
I've tried McSPI3 & McSPI4, and I got the same result, RX all zeros.
All the things I checked is the same with Kevin.
In my opinion, I also thought mcspi module may have problem to receive
data.
I have viewed the silicon errata of omap3530, but there is no function
exception about this issue.

Kevin, do you use gpio to simulate hardware spi?
Could you give me some sample codes to do so?
This would save me much time.

Philip, I have made some patches on my website.
http://www.csie.nctu.edu.tw/~yuchih/spi/
Hope it helps!
Maybe you could help us to figure where is the problem.

Yuchih

On Jan 16, 5:04 am, "Philip Balister" <philip.balis...@gmail.com>
wrote:
> This is a great thread, I need to do something very similar. Is the
> code you guys are talking about available anywhere? At least the bits
> to laod the mcspi driver and setup the pin mux?
>
> This would save me loads of time!
>
> Philip
>
> On Tue, Dec 16, 2008 at 11:59 AM, Kevin Uhlir <kev...@flochart.com> wrote:
>
> > Thanks forallwho have tried to help on this. Its still not working.
Message has been deleted

Keith Williams

unread,
Jan 23, 2009, 9:10:24 AM1/23/09
to beagl...@googlegroups.com
Yuchih wrote:
> I've tried McSPI3 & McSPI4, and I got the same result, RX all zeros.
> All the things I checked is the same with Kevin.
> In my opinion, I also thought mcspi module may have problem to receive
> data.
> I have viewed the silicon errata of omap3530, but there is no function
> exception about this issue.
>
One of my team also was having issues with this and posted a question or
two late last year. We've been working on other items and haven't
revisited this lately.

A couple of things to check (that I've thought of, but haven't looked into):

1) Make sure that OE is pulling recent code.....at one point we found
the recipe was pulling code some 5 months old off of the git tree
2) Are the IO's being setup properly (I think this is still being done
in Uboot)? I seem to remember several places that this could be mucked up.
3) There are some MCBSP driver patches that I'm not sure if they've made
it into the main tree.....Tony Lindgren did the work with patches being
released around September 24th.

Let me know if you have any success.

Thanks,

Keith

Kevin Kemper

unread,
Feb 5, 2009, 6:59:25 PM2/5/09
to Beagle Board
I've been having the same problem. I have verified that everything is
electrically connected (using GPIO) and that valid data is running
through the lines. I can watch data come into the omap on the miso
lines with my scope but the mcspi driver returns all zeros. I'm
wondering what the pandora people are doing to get around this problem
because they are using the same spi touchscreen chip as my project. I
wonder if everyone is using bitbanged spi...

~Kevin Kemper

G2

unread,
Feb 13, 2009, 7:10:53 AM2/13/09
to Beagle Board, kev...@flochart.com
Kevin,

That sounds quite interesting. Could you please post your bit bang
code?

Thanks in advance,

Gregoire

On Dec 16 2008, 10:59 am, "Kevin Uhlir" <kev...@flochart.com> wrote:
> Thanks forallwho have tried to help on this.  Its still not working.
>
> In the mean time, I've coded up a simple bit bang spi routine, set the
> padconf registers to mux the mcspi3(mode 1) pins to gpio(mode 4), and now I
> can receive data through the bit-bang routine.  This proves the
> hardware/wiring/traces and everything else is correct.  Since I can set
> padconf to gpio/mode4 and input enable, as appropriate, it proves I'm
> setting the right registers.  This is only a temporary work around, so I can
> continue, while looking for the real solution.
>
> Unless there is something I'm overlooking, I don't believe the mcspi module
> is working for receiving data.  Has anyone else had success using mcspi3
> and/or mcspi4?
>
> Kevin
>
> > -----Original Message-----
> > From: beagl...@googlegroups.com
> > [mailto:beagl...@googlegroups.com] On Behalf Of Kevin Uhlir
> > Sent: Sunday, December 14, 2008 5:00 PM
> > To: beagl...@googlegroups.com
> > Subject: [beagleboard] Re: MCSPI TX works fine, butRXallzeros
>
> > I put some more debug code in the driver, and I see the TRM bits are
> > correct.  The SCLK, MOSI, and CS0 areallworking fine.  I see the
> > clock, I
> > see CS operating, I see MOSI changing according to the data sent, in
> > sync
> > with the clock.   I just tried SYST setting some values in, but it
> > didn't
> > fix the problem.  Also, the documentation says SYST is only used in
> > system
> > test mode, which is not enabled.
>
> > I decided to dumpallthe registers in the driver, just before the
> > transfer
> > is starts:
>
> > SYSCONFIG (d80b8010)=00000001  AUTOIDLE
>
> > SYSSTATUS (d80b8014)=00000001  RESETDONE
>
> > IRQSTATUS (d80b8018)=00000001  TX0_EMPTY
>
> > IRQENABLE (d80b801c)=00000000  no IRQ's enabled
>
> > WAKEUPENABLE (d80b8020)=00000000  no Wakups enabled
>
> > SYST (d80b8024)=00000000  nothing being tested
>
> > MODULCTRL (d80b8028)=00000001  SINGLE CHANNEL MODE, MASTER, not
> > SYSTEMTEST
>
> > CHCONF (d80b802c)=001103e0  PHA=0, POL=0, CLKD=0x8, EPOL=1,
> >                             WL=0x7, TRM=0 (tx+rxmode), DMAW=0, DMAR=0,
> > > > > > I ran into a similar issue on the UART whereRXdidn't work due
> > > to U-
> > > > > > boot setting up another ball as theRXand I enabled the
> > > expansion
> > > > > > connector connected ball also asRX. I am guessing that caused
> > an
> > > > > > internal conflict since there are 2 sources driving the same
> > > line. I
> > > > > > fixed this by putting the other ball in GPIO mode.
>
> > > > > > On 12/14/2008 12:45 am, Kevin Uhlir wrote:
> > > > > > > I've been struggling with a problem with MCSPI3 and MCSPI4 on
> > > the
>
> > > > > > expansion
>
> > > > > > > connector.  I've enabled SPI3 and SPI4 and I'm testing with
> > > spidev.
>
> > > > > > I've
>
> > > > > > > got the PADCONFs set correctly -- (I've verified this more
> > > times
> > > > > > > than
>
> > > > > > you
>
> > > > > > > can imagine).
>
> > > > > > > The problem isallSPIRXdata is zero.  TX Data goes out
> > just
>
> > > > > fine,
>
> > > > > > > appears out the SIMO line, along with SCLK and CS0.  I've
> > > verified
>
> > > > > > that the
>
> > > > > > > data is getting to the expansion connector.
>
> > > > > > > I've also configured the SOMI pad to have a pullup, which I
>
> > > > > verified
>
> > > > > > on the
>
> > > > > > > pin itself, which should produceallones forRXdata, but I

Yuchih

unread,
Feb 15, 2009, 10:10:18 PM2/15/09
to Beagle Board
hello,

I have tried this patch. It works well for me!
http://lkml.indiana.edu/hypermail/linux/kernel/0810.2/1536.html

yuchih

G2

unread,
Feb 16, 2009, 3:27:24 PM2/16/09
to Beagle Board, liuy...@gmail.com
Yuchih,

Thanks. I have patched my kernel and modified .config. I've read the
intro of the patch but I'm unsure how to modify mach-omap2/board-
omap3beagle.c to leverage this feature. Can you please paste your
code? If you don't have time, don't bother with a patch, snippet would
be enough,

Grégoire


On Feb 15, 7:10 pm, Yuchih <liuyuc...@gmail.com> wrote:
> hello,
>
> I have tried this patch. It works well for me!http://lkml.indiana.edu/hypermail/linux/kernel/0810.2/1536.html

Yuchih

unread,
Feb 16, 2009, 8:53:01 PM2/16/09
to Beagle Board
Hello,
As information in the spi_gpio.h, there are two things you have to do.

1. register controller driver in arch/arm/mach-omap2/devices.c

diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/
devices.c
index 241e418..3ec6d04 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -14,6 +14,7 @@
#include <linux/init.h>
#include <linux/platform_device.h>
#include <linux/io.h>
+#include <linux/spi/spi_gpio.h>

#include <mach/hardware.h>
#include <asm/mach-types.h>
@@ -278,6 +279,22 @@ static struct platform_device omap2_mcspi4 = {
};
#endif

+/*** added by yuchih***/
+static struct spi_gpio_platform_data spi5_gpio_platform_data = {
+ .miso = 138,
+ .mosi = 139,
+ .sck = 137,
+ .num_chipselect = 1,
+};
+
+static struct platform_device spi5_gpio = {
+ .name = "spi_gpio",
+ .id = 5,
+ .dev = {
+ .platform_data = &spi5_gpio_platform_data,
+ },
+};
+
static void omap_init_mcspi(void)
{
platform_device_register(&omap2_mcspi1);
@@ -290,6 +307,7 @@ static void omap_init_mcspi(void)
if (cpu_is_omap343x())
platform_device_register(&omap2_mcspi4);
#endif
+ platform_device_register(&spi5_gpio);
}

#else

2. declare slave device in board-omap3beagle.c
In the following patch, I use spidev protocol driver.

@@ -404,13 +405,107 @@ static void __init omap3beagle_flash_init(void)
}
}
+static struct spi_board_info beagle_spi_board_info3[] = {
+ {
+ .modalias = "spidev",
+ .max_speed_hz = 200000,
+ .bus_num = 5,
+ .chip_select = 0,
+ .mode = SPI_MODE_1,
+ // this one uses GPIO 136 for its chipselect
+ .controller_data = (void *) 136,
+ },
+};
+
static void __init omap3_beagle_init(void)
{
omap3_beagle_i2c_init();
platform_add_devices(omap3_beagle_devices,
ARRAY_SIZE(omap3_beagle_devices));
omap_serial_init();
+
+ omap_cfg_reg(XXX_3430_MMC2_dat4); //cs
+ omap_cfg_reg(XXX_3430_MMC2_dat5); //clk
+ omap_cfg_reg(XXX_3430_MMC2_dat6); //somi
+ omap_cfg_reg(XXX_3430_MMC2_dat7); //simo
+
+ spi_register_board_info(beagle_spi_board_info3, ARRAY_SIZE
(beagle_spi_board_info3));

By the way, don't forget mux configuration for gpio pins.

yuchih

G2

unread,
Feb 19, 2009, 3:24:10 AM2/19/09
to Beagle Board, Philip Balister, liuy...@gmail.com
Many thanks. It's working indeed. As the same time, it seems that
Philip has made some progress on the SPI itself,

Grégoire

Yuchih

unread,
Feb 23, 2009, 1:56:26 AM2/23/09
to Beagle Board

ksuzuk...@gmail.com

unread,
Mar 10, 2016, 10:10:07 PM3/10/16
to BeagleBoard, liuy...@gmail.com
Hi, guy.

I had had the same problem.
But I solved it.

The problem was very simple.
We have to set "RXACTIVE" bit to CLK Pin's "Conrol Module Resiters(PINMUX)".

So dts file is follows
    spi0_pins: pinmux_spi0_pins {
        pinctrl-single,pins = <
            0x150 ( PIN_INPUT_PULLUP | MUX_MODE0 ) /* (P23) spi0_sclk.spi0_sclk */
            0x154 ( PIN_INPUT_PULLUP | MUX_MODE0 ) /* (T22) spi0_d0.spi0_d0 */
            0x158 ( PIN_OUTPUT_PULLUP | MUX_MODE0 ) /* (T21) spi0_d1.spi0_d1 */
            0x15c ( PIN_OUTPUT_PULLUP | MUX_MODE0 ) /* (T20) spi0_cs0.spi0_cs0 */
        >;
    };

And, we can see in "Technical Reference Manual" 26.2.3.
It is said "SPI serial clock (output when master, input when slave)"
And it also said "(1) This output signal is also used as a re-timing input. The associated CONF_<module>_<pin>_RXACTIVE bit for the output clock must be set to 1 to enable the clock input back to the module."


Михаил Голубев

unread,
Dec 22, 2016, 8:36:31 AM12/22/16
to BeagleBoard, liuy...@gmail.com, ksuzuk...@gmail.com
Many thanks ksuzik,

I had the same issue with mcspi0 as master. Setting SCLK to input by default solved it.

пятница, 11 марта 2016 г., 6:10:07 UTC+3 пользователь ksuzuk...@gmail.com написал:
Reply all
Reply to author
Forward
0 new messages