Interesting findings with SD card & PropGCC - some work, some don't

mindrobots · 2012-06-06 09:13

It took me a while to narrow this down - lots of unknowns in the mix.

The end result is I have a micro-SD card that doesn't work with the PropGCC SD driver but works fine with this Spin SD driver (John Twomey's FAT16 driver) and the SD driver from PropForth.

I'm testing a prototype board and also using PropGCC so at first I suspected my coding or the board. I then moved it to another board with same results. I then tried a different cars (FINALLY!) and my code worked. Went back to the prototype with the other card and it worked. Too the original card to a Quickstart and it worked with PropForth and Spin. The Prototype also worked with PorpForth and Spin. I finally closed the loop by taking the prototype and the known good card back to PropGCC and it worked with my code.

The only bad combination is the bad card and PropGCC on any board (tried Quickstart, prototype and Demoboard) - it just hangs when it goes out to access the SD.

The bad card is a Lexmar 2GB, the working card is a MicroCenter 2GB. Both are identically formatted in Windows. Both work fine on my desktop. I'm going to see if I have any other Lexmar's lying around to see if it's an individual problem or a class problem.

Just something to look out for when anyone is testing and sees unusual SD results or problems - it could just be a card that PropGCC is picky about but other drivers aren't.

Is there any debug info I can turn on in the drivers to see what's hanging it up?

Anybody want me to send them the card?

jazzed · 2012-06-06 15:12

Hi Rick.

Sorry you've had trouble. Usually reformatting a card fixes such problems.
If that doesn't work maybe one of our regulars can volunteer to have a look?

It would be nice to know if others have had any issues.

Thanks,
--Steve

Dave Hein · 2012-06-06 15:21

Rick,

Does the program return from the call to the mount routine? If so, can you print out the return code? The only other way to get debug info would be to make a copy of the file driver source files and add prints to them. I think there are a few compile-time flags you can enable to print some information.

Dave

mindrobots · 2012-06-06 15:22

Not a problem. I learned stuff so all is good! I'll try some other stuff. It's the only Lexar card I found in all my various boards so if it's a one off problem, no big deal. It would be interesting if other folks have seen anything. If any of the regulars want it for testing, just let me know.

pedward · 2012-06-06 15:37

What I suspect is that the card isn't formatted MBR. The Prop library needs an MBR to define the partitions, then format a partition. The old way of formatting a floppy without an MBR is how some SD cards are formatted. You can use the Disk management service under the Compute management administrative tools menu. Or fdisk.

Dave Hein · 2012-06-06 15:55

The PropGCC file code uses the same technique as FSRW for read the master boot record. If the card mounts with FSRW it should mount with PropGCC.

BTW, the PropGCC file driver code is located at http://code.google.com/p/propgcc/source/browse/lib/drivers/?name=b9987f5b83e7&r=9fbe64ee9ac2929ade75a0cbd85d96ae6d67c7ef .

mindrobots · 2012-06-06 16:26

Thanks for all the suggestions, I'll start working my way through them, starting with the formatting.....after nap time.

mindrobots · 2012-06-06 18:24

It was MBR formatted. I reformatted it. It's still MBR formatted.

I'm printing out errno when fopen fails. This is what I get with the Lexar card:

First thing I do Terminal File Demo ...
  Can't open 'abe.txt' for write: 12
 Can't open 'abe.txt' for read: 12
  Press any key ...

You guys are making me learn a lot of C!!

I'll look next to see if there is any deeper debugging I can turn on.

pedward · 2012-06-06 18:42

That's an EI, EI, EIO error.

pedward · 2012-06-06 18:51

Do you have 2 cards of the exact same size?

Normally I would dd the bad card to a file, then dd a good card to the bad card and try again. This would determine if the problem is hardware or format related. The MBR could be badly written, with a wacky cylinder/sector count.

I would be more than happy to diagnose these issues, it would be considerably easier if I had a "bad" card on hand.

I recall that Parallax has a bunch of SD cards that don't pass muster, if a couple of these showed up at my door, I can diagnose the failure and try to remedy it. Ideally the software should be changed so it works with the stock card, not the other way.

The best way I can think of diagnosing this remotely is to use a Linux box. Perhaps a live CD distro would work to "get in". Barring that, a disk image of the raw card would help a lot. The problem is that sometimes the MBR offsets are written in CHS or LBA mode, and Windows/Linux will happily go on using the messed up addresses until you literally zero out the MBR and rewrite it from scratch.

mindrobots · 2012-06-06 19:23

Perry,

I'd be happy to send the bad card to you if you think it will help "the cause". I have plenty of cards to take up the slack.

PM a mailing address to me and I'll toss it into an envelope.

Thanks for helping!

Heater. · 2012-06-07 01:18

Be warned. I have had lots of problems with SD cards on Peopeller and other platforms.
A number of times using dd to copy a card to an image file and then from image file to a similar card has seemed to work. But then comparing the two cards they would be different.
This caused a lot of head scratching and confusion.

pedward · 2012-06-07 11:09

Rick is going to send the card to me. I'll dissect the code and review the card and report back what the cause is. I may even be able to contribute a code fix, or outline how to fix the card.

jazzed · 2012-06-07 11:10

pedward wrote: »

Rick is going to send the card to me. I'll dissect the code and review the card and report back what the cause is. I may even be able to contribute a code fix, or outline how to fix the card.

Thank you sir.

mindrobots · 2012-06-07 11:21

The card is in the mail - if the USPS carries through as usual, Perry should have it next week.

prof_braino · 2012-06-07 13:20

Don't these SD cards have itty bitty uC in them, and these are custom programed with proprietary code at manufacture?

Wouldn't these differences just be errors in that one SD's code? I have heard that the super cheap discount cards that used to turn up in toyko we from the operator running the machine after hours with no quality control and then sell the results on the grey market. Maybe lexmark got a stray in the batch?

pedward · 2012-06-07 13:29

I strongly suspect the MBR has the partition boundaries indicated in an addressing format that is incompatible with the existing driver. LBA addressing mode has been standard for quite some time, but every now and then CHS sneaks in and has to be fixed. My first hunch is that the MBR addresses the partitions in CHS mode, which is breaking the driver.

pedward · 2012-06-14 00:49

I got Rick's card today and had an interesting experience I'll share.

Firstly, it's not a disk format issue. The SD cache loader is actually failing with an error #6, which is "card didn't init within 4 seconds". That's if I read the code correctly.

Here's the kicker, you can use the "write file to SD card" option of SIDE and it WORKS! However, the SD cache driver bombs.

The serial_helper that propeller-load uses is based on fsrw and the c3 sd comms routines, and this works. The sd_cache.dat driver is PASM that was written to work as a COG driver.

The things I'm seeing that are different is that the c3 sd comms use the counter as a shift register to write to the card, doing a shift per clock. This equates to 20Mhz with an 80Mhz clock.

The sd_cache driver communicates with the card using a simple PASM loop that sets the clock, tests a bit, sets the line, lowers the clock, then loops and sets the clock.

I will need to put my logic analyzer on the SD card to confirm, but I have three areas I suspect:

-Clock duty cycle is not 50% on sd_cache, causing timing issues with Lexar card
-Card initialization sequence does not perform low speed initialization (400Khz) and Lexar card is intolerant
-Card initialization sequence is not identical to FSRW and the slight differences cause edge case rejection by Lexar card

The SPI routines are completely different between the serial helper and the sd cache driver, which leads me to think that this may be the most likely cause.

I'll setup with my Logic analyzer and see what the differences are.

pedward · 2012-06-14 00:56

http://mfb.nopdesign.sk/datasheet/cat_d/MMC/spitiming.pdf

jazzed · 2012-06-14 19:06

@peward, Thanks for looking into this. Hopefully we can add a fix for it soon.

Interesting findings with SD card & PropGCC - some work, some don't

Comments