BB -xM Rev B not writing to some SD cards.

[cwall]

I have a BB -xM Rev B, serial no 4510xM751, which does not write
reliably to some brands of micro SD cards. BB can read from all the
cards fine but when the kernel needs to write to the card I get the
following errors, as shown by the following command.

root@beagleboard:/media/mmcblk0p1# dd bs=1024 count=50K if=/dev/zero
of=/media/m
mcblk0p1/speedtest.txt

[ 248.255889] mmcblk0: error -110 sending read/write command,
response 0x900, card status 0xe00
[ 259.867248] mmcblk0: error -110 transferring data, sector 752, nr
1, card status 0xe00
[ 276.210662] mmcblk0: error -110 transferring data, sector 2609, nr
1, card status 0xe00
[ 292.283935] mmcblk0: error -110 transferring data, sector 760, nr
1, card status 0xe00
[ 308.020874] mmcblk0: error -110 transferring data, sector 3801, nr
1, card status 0xe00

The only card that works OK is a Kingston Micro SDHC 4GB class 4
card.

The following cards produce the type of errors shown above.
PNY Micro SDHC 4GB class 4
ADATA Micro SDHC 4GB class 6

The test was done with the "xM TEST 20100820" image on each card.
All the cards work fine in an USB adapter on the desk top computer.
Any thoughts if this is a REV B type of problem, maybe a timing glitch
or something.
Thanks
Carl

[Gerald Coley]

There are no external components on the -xM to support the Sd card interface. It is straight out of the processor. One other aspect is that the voltage is 3.0V, which is at the lower end of the SD card specification.

 

I would look to the SW piece of the puzzle. Like, reading the card to determine the proper speed and timing for each card type in the SW and adjusting the timing accordingly.

 

Gerald

 

--
You received this message because you are subscribed to the Google Groups "Beagle Board" group.
To post to this group, send email to beagl...@googlegroups.com.
To unsubscribe from this group, send email to beagleboard...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/beagleboard?hl=en.

[cwall]

Gerald
Thank you for the feedback, looked at the schematic and as you said
it is a simple circuit for the SD card interface. Did find some talk
about problems back in June about software changes in the mmci-omap-hs
driver on the Omap Processor Linux development list, so maybe this is
related. Do not know if the validation test kernel has the
corrections in its driver. Maybe some of the software kernel chaps
will have some thoughts on the subject and suggestions.
Thought the change in processor might have required a change in
trace routing which may have effected things, which is why I thought
of the hardware side first. Do you know if the -xM board is using the
SPI mode or native mode for communication with the SD card?
Guess it is time to start learning how SD cards interface works in
more detail.
Cheers
Carl

> > beagleboard...@googlegroups.com<beagleboard%2Bunsu...@googlegroups.com>
> > .

[Gerald Coley]

To my knowledge, the Uboot code is hard coded to a set frequency, Hence my response as it relates to looking at the SW as the issue. I am not sure as to the state of the Kernel. But, if it can't read the card reliably, then the Kernel would have issues booting and potentially other issues as well, like possibly corruption of the SD card during a write process.

 

The processor uses the SPI mode in the internal ROM if I remember correctly. I believe it switches to the 4 bit mode after the UBoot comes up, but I may be wrong.

 

You could switch to the latest demo kernel and repeat the tests. You could also try other versions of the kernel with you know set of cards and see what results you get then.

 

Gerald

 

To unsubscribe from this group, send email to beagleboard...@googlegroups.com.

[Eric Fung]

I have 64 original Beagleboards used in my Manufacturing Testers.  I encountered the same problem with RiDATA "Lightning Series" 2GB SD cards with the original BeagleBoard a month ago. I bought a bunch of them. The failure rate on read is higher than 50%. I tested the RiDATA cards on camera and PC. They work perfectly fine. Finally,  I gave up and bought a bunch of SandDisk Ultra II cards to replace them. They are much faster to write to. I have been using PNY "OPTIMA" 60X 2GB. They are very slow on write. But, these SD cards are only used to store the kernel and rootfs. So, my suggestion is to use SandDisk cards.

The Linux MMC driver is fine. I use the second MMC bus on the Beagleboard to test my company's product.

-Eric

[cwall]

Gerald
My first tests where made with the Angstrom demo image, Android
image and an Ubuntu image using the procedure outlined in an article
on "Booting linux on the Beagle -xM" on the IBM developer web site.
The Android image just got to the boot splash screen, Ubuntu got to
the setup scripts but could not save the add new user information and
the script finally failed after a few attempts to create the new user,
and the Angstrom demo would get to the desktop on the first boot of a
fresh image and could play the movie via the short cut, but would then
fail to get to the desktop most of the time on the next boot cycles.
Next I got the serial port connected and working, and could see
after the Angstrom demo got to the desktop, that write errors started
to occur. I then logged in via the serial port and did some write
tests using the vi editor. but the results where not repeatable but
suggested it might be file type related. That is when I downloaded
the validation image and loaded that on the cards as it would be
running completely in ram for any testing of the cards.
Then I started to use dd to write larger files and saw that the
write failures happened on all the file types, dos, ext2 and ext3
partitions. A few days later found a Kingston card and it ran the
demo image with no write errors on the serial port and also passed the
dd write test of larger files with no write errors.
So after seeing no posting of this type of error on the message
board, I made a posting of my results as I did not know if it was just
my board, or my setup, or this production run of boards, or a general
xM problem. As the only problems I could see on the board where
related to creating the image on the SD card or power supply related
when trying to power xM from a USB cable. Since I am using a 4 amp
power supply and all my images could boot the kernel, I seemed to have
a new type of fault.
I have ordered some other brands of 4 Gig cards so I will have a
larger selection, to see if the ones that are failing have a common
feature.
Since I do not have access to a storage scope, I will not be able to
add information about the electrical signals going or coming from the
board related to the SDHC card, or check supply voltage to the
different SD cards during the write cycle.
At least I know at this point the Kingston cards do work for me, but
I have this itch about why the other brands of cards I have do not.
Also it would be nice if they could add a SD card test script to the
validation image, to test the sd card and also give you an idea of the
write/read speed of the brand of card you where using.
Cheers
Carl

> > <beagleboard%2Bunsu...@googlegroups.com<beagleboard%252Buns...@googlegroups.com>

[Steve Sakoman]

Gerald,

I just RMA'ed an xM because it could not reliably read the kernel to
boot from any SD card I have (and I have quite a few brands).

The replacement xM works perfectly with all of the cards that I have tried.

This of course isn't conclusively a hw issue, since the linux driver
timer could possible be marginal, but it does at least raise some
suspicion that there might be some hw issues.

Steve

[Steve Sakoman]

On Thu, Dec 30, 2010 at 8:32 AM, Steve Sakoman <sak...@gmail.com> wrote:
> Gerald,
>
> I just RMA'ed an xM because it could not reliably read the kernel to
> boot from any SD card I have (and I have quite a few brands).
>
> The replacement xM works perfectly with all of the cards that I have tried.
>
> This of course isn't conclusively a hw issue, since the linux driver
> timer could possible be marginal, but it does at least raise some
> suspicion that there might be some hw issues.

Can't type this morning! I of course meant:

"since the linux driver timing could possibly be marginal"

Steve

[Gerald Coley]

I just ordered a bunch of cards to go back and run them through a few boards including the ones you sent back. I would like to see the UBoot and all Kernel actually read the card to determine the proper speed. I am not sure this is the case today. There is also a question I have as to wheter or not the volatge is being set to 3V or 3.15V. It needs to be set to 3.15V to give more margin.

 

Gerald

--

[Eric Fung]

Gerald,

The SDA specify voltage from 3.0 to 3.6. I think 3.3V will be appropriate. If the SD VCC is configurable, why not 3.3V? I think the SandDisk cards are ultra user friendly. I have a bunch of RiDATA "Lightning Series" 2GB card that has very high failure rate (60%) on some Beagleboards.  After I figured out those "failure cards" are perfectly good on PC and cameras, I found good deals and bought 50 SandDisk Ultra II 2GB cards instead. Previously, I used PNY OPTIMA 60X cards; but they are ultra slow to write to.

-Eric

[Gerald Coley]

Yes, but the PMIC cannot provide 3.3V. The best it can do is 3.15V. That is the reason it needs to be  3.15V.

 

Gerald

[Eric Fung]

I think 3.15V will fix the problem. It is because some of the RiDATA cards that I have work okay. I initially bought 2 RiDATA cards to test them first. They both work okay on my  "desktop" Beagleboard. Then, I bought 48 more. Problem followed... So, I think 3.0V is indeed marginal.

[Gerald Coley]

I am hoping that is the case.

 

Thanks!

 

Gerald

[cwall]

Did some more tests this weekend and the following cards worked OK
with the writing of large files.

Lexar micro SDHC 4 GB class 2
Transcend micro SDHC 4GB class 6
SanDisk micro SDHC 4 GB class 2

Carl

[Steve Sakoman]

I believe that there may be an additional issue with the OMAP hsmmc
driver's computation of dto (the data timeout value). I've been able
to make most cards that don't work function with an increase in the
calculated dto value.

There's a thread on the linux-omap list discussing this.

Note that I too believe that 3.15V would be a good idea, I just don't
think that is the only issue.

Steve

[cwall]

Steve
I think you are right, feels like the driver is making some wrong
calculations based on what it is getting from the sd cards, and some
cards can work with it and others can not.
Will check out the linux-omap list.
Carl

On Jan 15, 6:41 pm, Steve Sakoman <sako...@gmail.com> wrote:
> On Sat, Jan 15, 2011 at 12:38 PM, cwall <cw...@pathcom.com> wrote:
> > Did some more tests this weekend and the following cards worked OK
> > with the writing of large files.
>
> > Lexar  microSDHC4 GB  class 2
> > Transcend microSDHC4GB class 6

> > SanDisk  microSDHC 4 GB  class 2

[Steve Sakoman]

On Thu, Dec 30, 2010 at 5:58 PM, Eric Fung <erick...@gmail.com> wrote:
> I think 3.15V will fix the problem. It is because some of the RiDATA cards
> that I have work okay. I initially bought 2 RiDATA cards to test them first.
> They both work okay on my  "desktop" Beagleboard. Then, I bought 48 more.
> Problem followed... So, I think 3.0V is indeed marginal.

Well, I finally received my microSD card extender so I was able to
probe the mmc card this morning.

I turns out that u-boot is using 3.0V for mmc, but the kernel mmc
driver switches to 3.15V.

So we aren't going to get a magical fix from the switch to 3.15V since
we are already there.

I was able to get most cards working with the following patch to the
dto calculation:

http://www.sakoman.com/cgi-bin/gitweb.cgi?p=linux-omap-2.6.git;a=commitdiff;h=381b62d716a8568d4210c5aa80d3dc0b5e0cdd6b

However I still have 2 cards which will not work reliably on my OMAP
systems: a SanDisk 4GB Class 4 card and and an ADATA 4GB Class 6 card.

Both cards work properly on my desktop system using a SanDisk USB
dongle, which powers the cards at 3.43 V.

An interesting experiment would be to hack up a board to supply 3.3V
to the card to see whether that fixes the issue. I'm not willing to
sacrifice a board to the cause though :-)

Steve

[Gerald Coley]

Well, let me see what I can do in the way of a HW hack. It may be tough to do, but let me see what is possible.

 

Gerald

[Steve Sakoman]

On Mon, Jan 17, 2011 at 7:55 AM, Gerald Coley <ger...@beagleboard.org> wrote:
> Well, let me see what I can do in the way of a HW hack. It may be tough to
> do, but let me see what is possible.

Actually it might be simpler to use an extender to do the hack, there
is easy access to the signals with one of these:

http://www.hwtools.net/ExtenderBoard/TFEX.html

Sparkfun also sells a simpler equivalent (that's the one I got):

http://www.sparkfun.com/products/9419

Steve

[Gerald Coley]

Nope. Won't work. You have to power the logic inside the processor as well. This means isloating that pin from the PMIC as well.

 

Gerald

[Andrew Harris]

Hi -

I need to know where the screw mount holes are located. I looked in the users guide, but no diagram has actual hole locations. Can someone point me to a good diagram for this?

thanks,
-andrew

[Gerald Coley]

 

Download the free Allegro viewer from here:

 

http://www.cadence.com/products/pcb/Pages/downloads.aspx

 

Then download the Allegro PCB files from here:

 

http://beagleboard.org/hardware/design

 

The allegro tool has a nice measurement tool for measuring distances.  You could also use the Geber files and a Gerber viewer as well.

 

Gerald

[Eric Fung]

Good detective work! Will someone fix the u-boot to access the card slower? I built u-boot a year ago. But, I do not want to deal with now. My work around is to use high tolerance SD cards.

Don't border to test your fix on the expansion header. It is because the output voltage is 1.8V. You need to use a voltage translator to shift the MMC IO voltage.

-Eric

[Seppo Nikkilä]

Hi Andrew,

Now when you can measure the locations, please let us all know:

1. The distance of the mounting hole centers on the loner and the shorter side
2. The distance of expansion connector pin #1 from the nearest corner ((x, y)

These measures are valuable for us all expansion board constructors.

I am designing my expansion boards so that BB and my boards face solder
sides to each others. BB has the female socket connector.
This arrangement allows easy access to the components on both boards
and the use of the JTAG.

Thanks for the measures in advance,
siñ

--
You received this message because you are subscribed to the Google Groups "Beagle Board" group.
To post to this group, send email to beagl...@googlegroups.com.
To unsubscribe from this group, send email to beagleboard...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/beagleboard?hl=en.

--
Developing next generation wireless audio

[Jacek Radzikowski]

I created for my kicad designs symbol and component for BB-xM. The
location of the mounting holes and the main expansion header have been
board-verified, the remaining expansion headers were verified only by
"eyeballing" (but seem to be correct).
Hope it will be helpful.
beagleboard-xm.lib.rename should be renamed to beagleboard-xm.lib
before importing to kicad.
regards,
j.

2011/1/19 Seppo Nikkilä <seppo....@innovativeideas.fi>:

--
Given a choice between two theories, take the one which is funnier

[Seppo Nikkilä]

Thank you for the information!

It would be interesting to know what kind of expansion
boards you have developed.

I have a few HD audio expansion boards for BeableBoard C4:

24-bit 192 kS/s DAC with audio post processing (I/V, filters)
24-bit 192 kS/s ADC with microphone preamplifier
4 channel HDMI selector with I2S audio decoder

The first one is tested and works well, the other two are
in prototype assembly at the moment.

Best regards,
siñ

[Jacek Radzikowski]

For now it was just a simple level shifter for I2c and a power supply.
I'm going to use BB as an embedded controller in an UAV I'm building
and with this prototype I wanted to verify some ideas about powering
the board from an external power supply and to experiment with i2c.

j.

2011/1/20 Seppo Nikkilä <seppo....@innovativeideas.fi>:

[Seppo Nikkilä]

Interesting project - keep me informed on your progress!
I designed and built a 5V/3A switching power supply for
BB. It can take external voltage from any 6 to 24 volt DC source.
If it is for any use to you, I can email the schematics and board lay-out. The board is approximately 2 cm x 3 cm.

siñ