eMMC driver (Can now read data in 8-bit mode!)

Rayman

From the eMMC vs HyperFlash thread, I've bought some stuff to hook up a eMMC chip to the P2. (that thread is here: https://forums.parallax.com/discussion/169987/)

Fortunately, the thing came with a uSD adapter that I can use to get some code working (see pic).

I tried regular uSD code (FSRW) on it and it fails completely.
This is because this thing uses the MOSI pin (they call it CMD pin) in a bidirectional manner.

I skimmed through JEDEC Standard No. 84-A441 and found the details I needed to get started...

The first thing to do is send CMD0 with no parameters.
Then, do CMD1 to get the OCR (operation conditions register).
The attached code does this and the response looks legit. Yeh!

Update: "..test2f" can now read block #0 data from eMMC chip using uSD adapter.
Update2: "..test3b" can now read 8-bit bus data using homemade adapter.

Rayman

Here's the output of the above on serial terminal:

Init then Sending CMD0

R1 = 3F
R2 = 40FF8080
R3 = FF

Should say "CMD0 then CMD1"

Peter Jakacki

If you want more interaction with the SD and then eMMC, you can drop down into TAQOZ in ROM with "> space esc" and issue commands and toggle pins all you like. There are high level commands for sure such as !SD which inits the SD and returns with the ocr, or MOUNT to mount the FAT32 volume, and DIR etc, but all the clocking bits and SPI stuff is directly accessible.

Issue a CMD0 and also a CMD8 with $1AA for operating conditions request etc.

TAQOZ# 0 0 CMD . --- 1  ok
TAQOZ# $1AA 8 CMD . --- 1  ok

Then read the OCR response as 32-bits (SPI Read Long) and print as a long (.L).

TAQOZ# 0 SPIRL .L --- $0000_01AA ok

This is the precise reason that TAQOZ is in ROM. It's not just a language, it's a tool.

btw, I just revisited TAQOZ in ROM and while it doesn't have the bells and whistles since it is packed into 12k, you can still do a lot. If you need to change the pins that the SD interface uses, you can specify it as a long in dot decimal notation if you prefix with an ampersand like this &cs.miso.miso.sck -
For example suppose we connected the clock to P34, the data in of the SD to P33 and the data out of the SD to P32 and because we are higgerly-piggerly the card select to P37. We could specify the pinout with &37.32.33.34 and while there isn't a direct word to change it, we can overwrite the sdpins constant and check it like this:

TAQOZ# &37.32.33.34 ' sdpins 2+ ! ---  ok
TAQOZ# sdpins .L --- $2520_2122 ok

Rayman

What I’m doing now isn’t really spi...

Closer to i2c...

I’m supposed to have a 10k pull-up on the Cmd pin but seems to work without it.

Peter Jakacki

SD cards have a pullup internally on the CS pin, and there always seems to be a weak pullup on most inputs too, although I haven't checked this lately. SPI or I2C, it doesn't matter, it is just as easy. At present I am talking to the UB3 chip via I2C and sometimes I drop down into the primitives, even constructing a test that I might then define as a word in the dictionary, to reuse.

A quick manual check of sending a $36 as an address and a command $10 and data byte $33.

I2C.START $36 I2C! $10 I2C! $33 I2C! I2C.STOP

If I'm happy with that I might make that into a general purpose word for this:

pub UB3CMD ( data cmd -- ) I2C.START $36 I2C! I2C! I2C! I2C.STOP ;

Then I can just type $33 $10 UB3CMD or supply any other parameters interactively.

I'm just making the suggestion as a reminder that this is built into the ROM and is always available, and only needs a terminal and it helps to have some kind of text editor. (I2C isn't in the ROM itself, but is easily added, or just use the full version)

Rayman

I'm trying to figure out how to calculate the CRC7 at the moment.
I have C++ code that works, but my Spin2 code doesn't for some reason.

Also, there seems to be some other kind of CRC7 with the same polynomial that gives a different result... strange...

BTW: That response from the card isn't what I'm looking for, as I see it now. I need to give it a different parameter for CMD1 to proceed...
Which means figuring out the CRC...

Peter Jakacki

My CMD word cheats a little. Until the card is properly in SPI mode, you need to supply a CRC. Once it is in SPI mode it ignores the CRC, so I have this little line that sets one of two CRCs.

---	send a crc of CMD8 or CMD0 - others ignore value
	sdcmd C@ IF $87 ELSE $95 THEN SPIWB

So if it is a 0 CMD it uses $95, but an 8 CMD needs $87. Just cheat with a CMD1 if that's the case.

Rayman

I tried turning off crc but it didn’t work....
Maybe I have to get through init first.

Rayman

I found some c code for crc that works. Just have to convert to spin2

Wuerfel_21

Rayman wrote: »

I found some c code for crc that works. Just have to convert to spin2

The P2 has hardware CRC instructions. Do these not work for this or did you forget about them?

Rayman

I may have to look into that.
The mmc version seems to be strange though

Rayman

Think I figured out the crc7. If I paid more attention to the C code I found, it would have been easier.
Seems you do 8 bits of crc for the 5 bytes of cmd+parameter, then do 7 bits of zero.
Finally, of course, you left shift and add 1.

Got it from the .zip file here: https://www.eetimes.com/heres-the-answer-to-crc-7-algorithm-for-the-sd-card/#

Rayman

I'm finally able to do CMD2 and getting card information that looks correct.

potatohead

Nice!

What's the advantage of these chips over the other solutions we've got so far? Sorry if I missed that. Read your progress report and was just wondering.

Rayman

It's big, like an SD card. But, has an 8-bit data bus option. (also 1 and 4 bit data bus options).

Rayman

Got it reading data! Updated top post with file that reads block#0
Ends in "55 AA", so I think it actually works!

Cluso99

WooHooo. Well done @Rayman

Rayman

Thanks. Big question for me now is... How fast can we read in data with this?

Just looking at this: https://elinux.org/images/9/91/Clement-sd-mmc-high-speed-support-in-linux-kernel_0.pdf

The DDR50 mode looks like it should work. That'd give us 50 MB/s compared to the < 3 MB/s we get now with uSD.

That's quite a boost!

If it's true, could do things like switch between 1080p images in HyperRam faster than the blink of an eye.

And do 16bpp uncompressed video at 480p resolution.
(That might be such a good idea though because you'd burn through 16 GB in 5 minutes...)
(sidetrack: we need to get jpeg decompression working!)

Rayman

Actually, maybe there's some way to use the HS400 mode... That would be awesome.
Perhaps the P2 pins would recognize 1.8 V as logic high? Should I think...

Maybe can use the DAC to give 1.8 V output...

I'll just try 3.3 V for now.

Rayman

Got my handmade adapter all wired up. Hope I did it right...

Might have to move CMD to P8 and just tie RST to high and remove STRB.
That way, could use over on basepin #48 side of the board...

Rayman

Wow, I'm lucky I just happened to have my P59 pullup switch on when I was testing with uSD card adapter...

I see now that (unlike uSD cards) this thing really does need a pullup on the CMD (miso) line.

Rayman

Got 8-bit mode working! Also, using internal pullup on CMD line (mosi).
Does block read at 13 MHz here. But, think can get that up at least to 25 MHz.

Rayman

BTW: The uSD adapter had me thinking there is a chip select pin... but there isn’t.

There is a new RESn pin though... I’m not sure yet if this can just be tied high.

rogloh

This effort looks good Rayman. I do like the capacity and write speed advantages of eMMC vs HyperFlash for file system use though that 200-333MB/s HyperFlash read speed is tough to beat on the P2. There'll be plenty of uses for both types of memory.

Sharing those data pins is an interesting idea for pin constrained setups but you'd really need a combined HyperRAM/Flash+eMMC driver to do that so there are no collisions. Unfortunately I've got no more room in my Hyper driver COG to add that, plus being slower to access it would mess up any real-time video transfers anyway