StarterWare SD Card driver

Dmitriy,

Unfortunately, StarterWare for OMAP-L138 does not support the MMCSD peripheral.  We don't have plans to support that peripheral in the near future, but it is possible we will add it some time down the road.  An updated release is coming sometime next month, but it will not add support for MMCSD.

We do support USB mass storage class, so you should be able to access an SD card using a USB adapter.  I have not tried this out myself, but I recommend testing your SD card (plus adapter) with the "usb_host_msc" example application.

Hope this helps.

hi, Joe

I'v find some files in drivers project location - hs_mmcsd.h and hs_mmcsd.c. there are also hs_hw_mmcsd.h file and some defines for MMCSD in hw_sysconfig_OMAPL13.h. is that all "garbage" from last reliases or from reliases for another chips? soc_AM335x.h  file also exists in package.

I would like to use that information and make my own MMCSD API in StarterWare stile. I will publish my progress here or elsewhere according to your advice.

regards, Dmitriy

Dmitriy,

The "hs_mmcsd" source files and headers are used by a different MMC/SD peripheral present in some other TI devices, like AM335x.  They're present because StarterWare supports a variety of different devices and we haven't done a perfect job eliminating unused files from the individual releases.  I apologize for the confusion.

You might be able to use these files as a starting point for your own MMC/SD code, but I recommend looking at the OMAP-L138 TRM to see how the MMC/SD peripheral differs in that device (i.e. as compared to AM3359).  You would likely need to make significant changes to the hs_mmcsd.c/h files as well as as hw_hs_mmcsd.h and soc_OMAPL138.h.

Hope this helps.

.. still debuging low level. strange behaviour of cards - like they was initialised to 1-wire mode.

I'v modified gpio exemple for testing SD driver. when single block read command is sent to card correct response is sent in return. then data is comming from card, but only on DAT0. in stat0 register we get CRC error. similar errors with write or read commands in 1-wire or 4-wire modes.

I will try to fix it as I can. maybe the problem is in my EVM - one time I killed fat with writing 0x5A to sector 1.

that is a sorses 8712.OMAPL138_SD_card.zip

Dmitriy

solved with ACMD6. DMA will be soon..

Hi Dmitriy ,

We appreciate your contribution to SD card driver development for StarterWare on AM1808.

Even we are working on similar type of development where we need to store & retrieve data from SD card using StarterWare on AM1808.

Can you please update us with your current work progress so that we can start off combined R&D regarding the same ?

Thanks & Regards,

Rohit

Hi Rohit,

without DMA SD transfers limited with 2,5 MB treshold.

unfortunately I'm not fimilar with DMA. update for sample progect is attached.

1067.SD_dma.rar

problems:

when bit 17 in CC0 EESR is manualy set with debuger (wrote 0x00020000), for example prior row 445 executed, everithing ok.

160 packets * 600 blocks * 512 B are sent within ~6 sekonds. this means ~ 8 MB/S write speed.

read operations are not implemented now. tested with 4 and 8 GB Transcent cards.

then how to set EER with software? DMA driver does not use EESR macro.

we'v also corrected couple *.xml files becourse of errors in CC0 section for ARM.

we still havent dicided would we use any file system or not. if you will make a port for ChaN's FATs I'll be happy.

with best regards, Dmitriy

problem solved:  add         EDMA3EnableDmaEvt(SOC_EDMA30CC_0_REGS,EDMA3_CHA_MMCSD0_TX);

after EDMA3RequestChannel(SOC_EDMA30CC_0_REGS, EDMA3_CHANNEL_TYPE_DMA,
                            EDMA3_CHA_MMCSD0_TX, EDMA3_CHA_MMCSD0_TX, 0);

(row 255).

now I should deal with fixed delay in

    if (DMAdone)
            {
                DMAdone = 0;
                delay(15);
                break;
            }
 some lupe with checking busy done bit I think..

modified from fixed delay to 'busy done' checking.

8037.gpioCardDetect.rar

regards,

Dmitriy.

Dmitriy, thank you for posting your code. It helped me get started with porting the AM335x StarterWare MMCSD example to the C6748. One slight typo though.

File: mmcsd.c
Function:MMCSDBusWidthSet()
From:
case MMCSD_BUS_WIDTH_1BIT:
  HWREG(baseAddr + MMCSD_MMCCTL) &= ~MMCSD_MMCCTL_WIDTH1_WIDTH0;
  HWREG(baseAddr + MMCSD_MMCCTL) |= MMCSD_MMCCTL_WIDTH1_WIDTH0_8BIT;
To:
case MMCSD_BUS_WIDTH_1BIT:
  HWREG(baseAddr + MMCSD_MMCCTL) &= ~MMCSD_MMCCTL_WIDTH1_WIDTH0;
  HWREG(baseAddr + MMCSD_MMCCTL) |= MMCSD_MMCCTL_WIDTH1_WIDTH0_1BIT;

It affects the data responses in the initialization commands.

Norman,

Nice to see that somebody else is working on getting SD cards to work. I also have some code that port starterware code (mmcsd_proto.c) to C6748. could you share your code, so we can combine our code?

Michiel

Getting permission to release code is tough enough for an employee. I'm a few layers of contractor from the client. It's taken me 2 weeks to get the AM335x StarterWare code to work on the C6748. This will be significant cost to the client. Not sure if I get permission. The lack of updates to StarterWare by Texas Instruments is quite frustrating. It is sad that so many companies have to repeat work that should already be done once.

I did not use most of Dmitriy's code as it was designed for PIO. The StarterWare example is EDMA. I did use the drivers from u-boot and linux as a guide. I also had to refer to the simplified SD Card specs in the few places that u-boot and linux were incorrect. The StarterWare code also issues a "select card" after the "set block len". On cards 2GB and less, this will probably hang the init process. It did on my Kingston 2GB test card. This bug will happen on the AM335x as well.

I work with Norm. We've requested permission to release the code from our client, who is funding the work.

I've posted the code is a new thread here:

http://e2e.ti.com/support/embedded/starterware/f/790/t/283373.aspx