public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Richard Retanubun <RichardRetanubun@RuggedCom.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [mpc8xxx_spi] help with using mpc8xxxx_spi and M25P40 spi flash
Date: Fri, 16 Oct 2009 17:33:15 -0400	[thread overview]
Message-ID: <4AD8E69B.4060706@RuggedCom.com> (raw)

Hello guys,

This is a derivative of my previous post for adapting mpc8xxx_spi to work with mpc8360e spi in cpu-mode.

I'm seeing something funny with using the 'sf probe' command, but not the sspi command.

Using 'sspi' command, I got a good response:

=> sspi 0 32 9f
spi_xfer: tx 9f000000 [32 of 32] bits
spi_xfer: ... 9f000000 written
[0] iR 0 ev 3 <-- [tm] isRead spi->event
[0] spi_xfer: rx 1fffa270 = ff202013
spi_xfer: transfer ended. Value=ff202013
*** spi_xfer: exit
FF202013
=>


When using 'sf probe', only the first tx data got transmitted (verified with scope):

sf probe 0:0
spi_xfer: tx 9fffd600 [8 of 8] bits
spi_xfer: ... 9fffd600 written
[0] iR 0 ev 3 <-- [tm] isRead spi->event
[0] spi_xfer: rx 00000000 = ffff0001
spi_xfer: transfer ended. Value=ffff0001
*** spi_xfer: exit
spi_xfer: tx 000102ff [32 of 40] bits
spi_xfer: ... 000102ff written <-- Never got sent out!
[0] iR 0 ev 1 <-- [tm] isRead spi->event
[1] iR 0 ev 1 <-- [tm] isRead spi->event
[2] iR 0 ev 1 <-- [tm] isRead spi->event
...
[1000] iR 0 ev 1
*** spi_xfer: Time out during SPI transfer
spi_xfer: transfer ended. Value=00000000
spi_xfer: tx 03ffffff [8 of 8] bits
spi_xfer: ... 03ffffff written <-- Never got sent out!
[0] spi_xfer: rx 1f5b4da8 = 13000000
spi_xfer: transfer ended. Value=13000000
*** spi_xfer: exit
SF: Got idcode 13 00 00 00 00
Failed to initialize SPI flash@0:0
=>

On the oscilloscope, even though "spi_xfer: ... 000102ff written" is shown,
I only see the first byte (9f) being sent and the clock stops there, explaining the debug printout during getting
rx data that shows the rx buffer never got any data

I have tried replacing the spi->tx = tmpdout statement (and all register access) with out_be##(&spi->tx, tmpdout)
in case the compiler is optimizing things out, but this makes no difference.

but if this is true, won't the MPC8349EMDS see this problem also?

What am I missing here?

Modified driver is attached.

Thanks for all the help!

- Richard


-------------- next part --------------
A non-text attachment was scrubbed...
Name: mpc8xxx_spi.c
Type: text/x-csrc
Size: 8218 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20091016/82df6c28/attachment.c 

                 reply	other threads:[~2009-10-16 21:33 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4AD8E69B.4060706@RuggedCom.com \
    --to=richardretanubun@ruggedcom.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox