PDA

View Full Version : Problem using OLED uSD Ccard



Squig
01-23-2008, 01:01 PM
Howdy,

Im using a μOLED-128-GMD1 on my current project.· It works great but I can't get the uSD Card to work.
I must be doing something fundamentally wrong.· I've got a Sandisk 1 gig card in it.

I've·tested it out with the following:

CON
_CLKMODE = XTAL1 + PLL16X
_XINFREQ = 5_000_000
VAR
long SAddr
byte uSD_Sector[512]
byte outDat[512]
byte i
OBJ
OLED : "uOLED-128-GMD1"
DELAY : "Clock"
PUB main
OLED.INIT
OLED.ERASE
DELAY.PauseMSec(20)
OLED.BACKGROUND(0,0,0)
DELAY.PauseSec(1)
OLED.FTEXT(0,0,0,255,255,255,string("Starting"),0)
repeat i from 0 to 255
outDat[i] := i
outDat[i+256] := i
OLED.FTEXT(0,1,0,255,255,255,string("Writing"),0)
DELAY.PauseSec(2)

SAddr := 1_000
OLED.WRITE_SECTOR(@SAddr,@outDat)

OLED.FTEXT(0,2,0,255,255,255,string("Reading"),0)
DELAY.PauseSec(2)

SAddr := 1_000
OLED.READ_SECTOR(@SAddr,@uSD_Sector)
OLED.FTEXT(0,3,0,255,255,255,string("Done"),0)





It gets all the way down to reading and locks up.
I've tried reading single Bytes but all I get is zeros.

Should that·code/card work?· Do I need to format the card in some way?

stevenmess2004
01-23-2008, 03:36 PM
Check your _XINFREQ. Doesn't the uOLED use a higher frequency crystal? You may also want to set the PLL to less as some people have reported trouble with it.

Steven

rjo_
01-23-2008, 09:58 PM
Steven... that's the 96 that you are thinking about the 128 doesn't have a Prop in it.

Squig... Jim?

Very timely thread. Great questions. If you don't get an answer here, try 4D's forum. This code must be available... no reason to re-invent the wheel, except that someone deflated the tires?

Sounds like the demo program works for you? There is a demo program that reads and writes images to the uSD. Have you tried writing bytes to specific locations?

http://www.newchicken.com/tag-gmd1.html Won't help much but it has some real nice adds:)

Please keep us posted on your progress...


Rich

JMLStamp2p
01-23-2008, 10:54 PM
I had the same problem and changed the _CLKMODE = XTAL1 + PLL16X to
_CLKMODE = XTAL1 + PLL8X "This seemed to repair the problem". Also might make sure that when you power up the Dispay the scrolling screen has SDK showing up.

JMLStamp2p

Squig
01-24-2008, 01:09 PM
Thanks for the suggestions but no go.

If I change the clock settings the OLED fails to·operate at all.
I ran the demo and it's not reading the uSD either.· But it's not locking up.

I have version 5 of the Pmmc so Im going to try updating that.

·

Squig
02-01-2008, 03:02 PM
Well, I found that the unit requires at least 3.9v using the uSD card, So I upped the voltage to 5v and I'm halfway there.

I can write Sectors and read bytes.· But I still can't read sectors.· It locks up every time.

rjo_
02-01-2008, 09:15 PM
Squig,

I got as far as reading and writing with your set up... before I destroyed my 128. I have a new one but haven't had time to play with it.
I found that I would get lock ups when I tried to check a bad sector. So, I just left the call out.

Rich

Squig
02-03-2008, 12:43 PM
How are you checking foir a bad sector?

I've found that the prop is successfully reading 256 bytes before it locks up.

rjo_
02-03-2008, 01:14 PM
Squig,

My light was on, but there was nobody home.

There is a call in the demo program... commented out. I'm working from memory. Tomorrow after the SuperBrawl I'll break out my fresh 128 and see how far I can get.

Again... sorry for the delay.

Rich

spry981
02-06-2008, 10:37 PM
I, too, am unable to read/write to my microSD card. I am using the uOLED 96 prop. I have a 5v input. The screen works perfectly.

I have been unable to find example code to read/write to the SD card. There was an example in the object exchange, but it failed after "mounting" the card.

rokicki
02-07-2008, 02:04 AM
Note that the OLED-128 and the OLED-96 use very different ways of driving the SD card.
The OLED-96 uses the Prop to talk to the card; the OLED-128 uses a different processor.

For the OLED-96, if you download the FAT16 R/W object from the object exchange, and
it doesn't work, chances are good your card is simply formatted wrong, probably in FAT32.
Read the README that comes with that object (http://tomas.rokicki.com/fat16work/README.txt
on the web) and try again. (I'm not sure but I suspect you may have to change the
mount line since I think the OLED-96 connects the SD card on different pins.)

If it doesn't work after that, try the sdrw_test object and let us know what happens.
I can pull out my OLED-96 and give you more detailed instructions if needed.

-tom

rjo_
02-07-2008, 11:25 AM
Tom,

If you pull it out... see what happens when you try to delete a file... when I delete files using the prop they still show up in the directory if that is because of what you are doing... it's ok for me... but if it is because of what I am doing then I need to do it right...thanks,


et al...

Other than what tom has said, I also suspect that you have to worry about how you take the card out of the computer... you actually have to "eject" it... you can just pop it out... it seems to mess up the formatting somehow. This is absolutely true on the Mac and I think it might be true with XP as well.

Rich

spry981
02-07-2008, 07:45 PM
I tried changing the base pin on the Mount call, started at 0, and worked my way up 10. No change in results.

I verified the card is formatted in Fat16, with 16K cluster size. The card is 1G in size (Kingston).

Do you have some working example code?

Thank you

rokicki
02-08-2008, 01:59 AM
rjo: if you are using the -128, I can't help at all; I don't have one of those and those do not use my code.

spry981: Tonight I'll get you some code.

rokicki
02-08-2008, 01:35 PM
Here's an object that demonstrates SD I/O on the OLED-96.

I had to change the low-level block read/write code to reflect the
pinout on the OLED card. This is temporary. The next version of
fsrw will require all four numbers to the start routine, rather than
assuming they are all the same. (Actually, the existing start
routine will still be there but there will be a new start4() that takes
the four pins in a specified order).

The "normal" pin order is do, clk, di, cs. The OLED pin order is
cs, clk, do, di.

The "base" pin for the OLED is 14.

Run the OLED_FSRW_demo. If it says "start returned" and shows
a number that's not zero, that's an error code; search for that
number in the source. (Note that negative numbers are error
codes; in assembly you'll find the numbers as *positive*.)

I'll have to write a better "tester" that does things slowly, step by
step, explaining what is happening at each step and, when things
fail, why they failed. But this should get you started.

-tom

Mike Green
02-08-2008, 01:43 PM
Don't forget that there is a version of FemtoBasic for the uOLED-96-Prop in the Propeller Object Exchange which has full support for the uSD card and includes support for the display (although not as the primary "console").

Squig
02-08-2008, 02:30 PM
My problem remains, I can't get the μOLED-128-GMD1 to do a successful sector read of the uSD card.
Has anyone had any luck doing this?

spry981
02-08-2008, 07:11 PM
Excellent! That worked perfectly. Thank you very much.

rokicki
02-09-2008, 03:39 AM
spry981: glad it worked! I'll probably update the fsrw this weekend so it's set up for this,
so other people don't need to reinvent the wheel. That also means I'll have to deal with
the MIT license issue, but no big deal.

Squig: No idea what's happening there. It does seem odd that it claims to successfully
write, but then the read hangs up. Did you verify that the data is actually written to the card
(the bytes 0..255 on the first sector)? Did you try throwing a scope on the pins and see
what is happening? What I would do in this case is such in the read sector routine inline
and add some debugging code to see where it hangs up. If you take out the write, does the
read routine still hang up? You may have to ask the manufacturer for some sample code
to read a sector. Where did you get the OLED-128 Propeller code from? Maybe the
author can help you.

Squig
02-09-2008, 05:43 AM
The write data is good.· I've been reading it in a byte at a time.
I know it reads the first 256 bytes before it locks up but I haven't checked to see if the data it reads is good.
I got the propeller code from the object exchange.

Squig
02-14-2008, 01:41 AM
Last post on this before I give up on this.

I changed the driver so that it only tried to read in 256 bytes, then compared the data to what it was writing.· I have already verified that the write sector work perfectly.

Anyway, when it does a sector read, it reads about 21 bytes correctly, then it drops about 16 bytes, reads 21 bytes, drops 16.

It could be a timing problem, it's hard to say.· I also wonder if it might be due to the serial buffer size of·16 bytes in the full duplex driver.· Since it's in a cog, I can't increase it to 512 and Im having a little trouble pointing elsewhere.