Does the HAL support MMC?

So in `SD_PowerON` there is a comment at the bottom that says `/* else MMC Card */`. `hsd->CardType` is never set to `MULTIMEDIA_CARD` which is defined in `stm32f4xx_hal_sd.h`, and read in `HAL_SD_WideBusOperation_Config`.

I have generated a project in the Cube and changed the `Mode` of `SDIO` to `eMMC 4 bits wide`, but it doesn't seem any different to the SD version.

I have the same exact question as pinkman.I'm working on integrating an eMMC, but I can't event make it through the HAL_SD_Init() since, from the code above, HAL libraries don't seem to fully implement it!I can't understand how I am supposed to build my eMMC app over HAL, since getting a "errorstate = Command Timeout" leads nowhere!

Exact same problem here. I connect an eMMC and I see the errorState returned by SD_PowerON() is SD_CMD_RSP_TIMEOUT. The function HAL_SD_Init() returns that error and so there is no further initialization. In the case of an SD card that function proceeds with a cal to SD_Initialize_Cards() but there is nothing there for an MMC card.

The SDMMC driver is available in STM32CubeF2/STM32CubeF4/STM32CubeF7.In F4 case, it is stm32f4xx_ll_sdmmc.c located under STM32Cube_FW_F4_V1.10.0\Drivers\STM32F4xx_HAL_Driver\Src.

As stated in this file:The SDIO features include the following: (+) Full compliance with MultiMedia Card System Specification Version 4.2. Card support for three different databus modes: 1-bit (default), 4-bit and 8-bit (+) Full compatibility with previous versions of MultiMedia Cards (forward compatibility) (+) Full compliance with SD Memory Card Specifications Version 2.0 (+) Full compliance with SD I/O Card Specification Version 2.0: card support for two different data bus modes: 1-bit (default) and 4-bit (+) Full support of the CE-ATA features (full compliance with CE-ATA digital protocol Rev1.1) (+) Data transfer up to 48 MHz for the 8 bit mode (+) Data and command output enable signals to control external bidirectional drivers.

So I recommend you to review this driver.

If we are speaking about different things, please correct me.If the issue is in CubeMX side, Yes I confirm that SDMMC is not yet supported even if you can select it in the Pinout wizard.

Hi Mayla! Thanks for replying!So, are we supposed to use the "stm32f2xx_ll_sdmmc" driver instead of the "stm32f2xx_hal_sd" when dealing with MMCs?I looked at the "stm32f2xx_ll_sdmmc" but it looks so poor compared to the second one, looking at its functions. For example it doesn't have "ReadBlocks" or "WriteBlocks" functions, it doesn't have DMA, etc.How are we supposed to use it, compared to using an SD card?

This answer from Mayla is indeed very troubling. I have no doubt that the low-level code in stm32f4xx_ll_sdmmc.c is to be used with an SD card and an MMC card. When I try to use stm32f4xx_hal_sd.c with an MMC card it uses those very functions however as has been stated above it simply returns an error which leads me to believe that ST has never tested with an MMC card or has never published a software solution for using one. The function SD_PowerON() in stm32f24xx_hal_sd.c does not set hsd->CardType = MULTIMEDIA_CARD, HIGH_SPEED_MULTIMEDIA_CARD or HIGH_CAPACITY_MMC_CARD even though the file stm32f4xx_hal_sd.h indicates that these are all supported SD Memory Cards. When does ST plan to publish a version of stm32f4xx_hal_sd.c that has been tested with MMC cards?

I would like to make use of a Kingston EMMC04G-S100 that has 4GB Capacity via an adapter that interfaces it to a microSD slot in an SD adapter that's connected to my ST eval board. That part is compliant with eMMC standard 5.0.

I am able to reliably use high capacity microSD cards in that slot with FatFs when I modify sd_diskio.c so that the SD_write() function makes use of BSP_SD_WriteBlocks_DMA() and the SD_read() function makes use of BSP_SD_ReadBlocks_DMA() since I founds that the non-DMA versions of those functions are unreliable and produce FIFO underrun errors as other people have reported on this forum.

>>I founds that the non-DMA versions of those functions are unreliable and produce FIFO underrun errors as other people have reported on this forum.

Agreed, polled is very fragile/marginal, issues with interrupts, and contention from LTDC, etc. Always use DMA here, so haven't seen often, but stock examples for F7-DISCO boards have been observed to be marginal and tend to fail when stressed slightly. Typically building on additional code. Problems more visible on DSI when pixel clocks pushed 30-60 MHz

To answer the initial question: "does HAL support MMC?":Now there is no MMC driver available. But it will be there in a coming release of the yCube FW packages. When deployed, you will be able to select MMC as SDIO mode from CubeMX interface.

Can you give us an update on MMC support? I have the latest CubeMX(4.15.0) and it seems like no support has been added since your last post several months ago. Like others, I am hoping to add eMMC support to my project and would really like to see proper configuration in CubeMX for this functionality.

Given how half baked these solutions have been over the years, I think the guiding philosophy should be that you can develop code for the parts you have chosen to use, or modify what is available to suit.

I certainly understand that sentiment Clive. However, in this case the CubeMX software allows you to do the initial configuration of MMC support by giving you the option within the SDIO config. Unfortunately, they have really only stubbed it out and what you end up with is just the GPIO pins configured and none of the other SDIO configuration code. You can understand that having Mayla indicate that support was forthcoming, it would be nice to use their offering. I have enough other things to work on so that I could wait a bit for a new version of CubeMX with MMC support, but without any idea how long that will be, I will likely need to figure it out myself. That would likely be pretty time consuming.

So if anyone from ST could provide a timeframe for MMC support, it would be appreciated. Even without CubeMX support, a simple, but complete code example would go a long way.

I would suggest you start shaking the tree from the distribution/sales contacts you have with ST, discussing with your FAE, and your eMMC part vendors and their FAEs. The direction of the ship is dictated by large customers, with specific requirements.

Most examples in the storage media space are of the "tada! look it works! kinda" category. ST proves a basic level of functionality, will minimal error propagation, and recovery. It doesn't look to me as if these things were written by people with much experience in the storage media space, but rather by people who have access to the protocol documentation and not much else. Being beholden to people with little more experience in the space than anyone else is not a strong position to work from.

Hi clive1, thank you for your interest!Actually I managed to hanve my eMMC working with a lot of code added to the ST HAL SD driver. It also works when used with USB MSC device class.Unfortunatly I have some problems with performances since my eMMC file transfer is really slow, but for the moment I'm quite happy with the result.

I too was able to get my eMMC chip working the FatFs and I would like to provide some details about what I did, so hopefully others might benefit as well. I was able to find what Nemui did and apply it. Thanks Nemui!

Just a quick recap. The basic problem is that the MMC configuration is not yet implemented/provided by CubeMX. You are able to select it, but the result is just the pins being configured and nothing else. What most have found is that basically stm32f4xx_hal_sd.c is missing the necessary code to support MMC. There are comments and various if statements that are in place for some code, but they really just set an error code and return.

I am using a custom board with a STM32F429NGH6 and Micron Tech MTFC2GMDEA (2 gig 8-bit eMMC).

My approach might seem a bit odd, but my goal was to leverage as much of CubeMX’s generated code as possible. Additionally, I wanted a very easy path to switch over to the sanctioned implementation once ST adds it to CubeMX. So I actually started by configuring my project for 1-bit SDIO rather than MMC, so that CubeMX would generate all the SDIO initialization code, etc. Then I just manually configured the other 7 SDIO pins in CubeMX (read below).

My steps for getting the FatFs working with eMMC:

In CubeMX, add/configure SDIO as “SD 1-bit” (we will switch to 8-bit after initialization in main.c).

Configure the other pins that would normally be used by MMC (8-bit in my case) the same as the SDIO_D0 pin that is configured when you add SDIO 1-bit support. The easiest way to figure out what pins these are is to set the SDIO to 8-bit and look at what pins were configured, then set the SDIO back to 1-bit and manually click on each of the pins and set them to the correct function (SDIO_D1 through SDIO_D7).

In CubeMX, add/configure FatFs using “SD Card”.

Export your project.

Modify stm32f4xx_hal_sd.c (see my modified version ATTACHED). **NOTE** remember that CubeMX will overwrite this file every time you regenerate your project so you need to keep it safe. I have the project under version control, so I can easily spot and discard the subsequently generated file each time I generate from CubeMX.

The result is a project that is ready for file I/O via FatFs. I have attached my main.c with a very simple file test. I tried to keep it as simple as possible, but please note that I have a USART configured for logging. If you are interested to see all the modifications that I made to stm32f4xx_hal_sd.c, open it and search for “for eMMC”. I believe that I added a comment including that text at the beginning of every block of modified.

I hope others may find this useful. I am not an expert with SDIO/MMC so I would be happy to hear from anyone with suggested improvements or if there are issues with this code. I’m happy to answer questions as well, but as I said, I’m no expert with this stuff.

Thanks,Craig

Attachments

thank you for your contribution. I'm trying to use an eMMC with the STM32F7 using your method but I'm not able to found your modifications to stm32f4xx_hal_sd.c (there is no "for eMMC" results in the attached file).

I'm just getting into this problem too as I need to support an eMMC with the STM32F7. What I have found so far:

1. The drivers in STM32CubeF7 1.6.0 seem to be the same as what is in STM32CubeMX 4.19.0

2. There is a HAL "driver" for MMC in those libraries, but you cannot enable it in the GUI.

3. There is no user level layers between the HAL MMC driver and FATfs, i.e. no "bsp_driver_mmc.c" or "mmc_diskio.c".

4. The HAL driver for MMC does not support memories over 2GB.

5. The HAL driver for MMC may not ever have been used or even compiled, as it has inconsistencies in function names.

I am currently working my way through all this. I have had some success by writing the missing bits, but still have some issues to fix. Card initialisation seems to work stepping through with the debugger but fails at full speed, and I also get errors when trying to write a file.

I'm working on getting the H7 MMC driver working, in the mean time I do have the F4 stuff working having implemented the CMD1/CMD2/CMD3 startup, and CMD7/CMD8 EXTCSD capacity detection. The regular CSD reports 1GB media with the Samsung 16GB and 32GB modules and this needs to be replaced with the values from the EXDCSD. There is a bunch of wrong headed code in ST's implementation which breaks the block addressing for cards it believes are 2GB or less.

I have furnished Lukasz Przenioslo with the modified files I'm working with on the STM32F412G-DISCO board, along with the ODROID modules and adapters.

Sounds like you are making good progress. I tried going down that route but eventually decided it was too much effort and instead imported Nemui's code on top of the F7 HAL library. It works with both eMMC (we made a SDcard containing an eMMC*) and SDCards of a variety of sizes. It does not use DMA, as that does not seem to work.

ST is using R0.12c (68300) as I recall. My own projects are using R0.13 (87030), names and RTC support changed in DISKIO mainly, and whatever bugs ChaN dug out of things. Lot of the larger media for me is using EXFAT, so wanted that to be solid.

I've got SDMMC working on our custom board with the STM32F767II using DMA together with CHaN's fatfs. Works great - the tough part I recall was getting the mkfs ( ) routine work and that requires good electrical characteristics.

Anyway, wanted to bring up the exfat problem - formatting exfat without paying royalty to Microsoft can only be done on a Windows machine ...

I'm using FatFS 0.13 in house, but using a more slap-n-dash approach to proving the eMMC using existing examples as much as possible. Makes the Diff/Merge easier to illustrate the key differences.

Lukasz's next target is the L4 so will likely port the modifications to that next.

I have F7 and H7 platforms so will work on those too. The H7 is more complex, they have some MMC libraries, separate from the SD, but no worked examples. I have an STM32H743I-EVAL, it has the more complex SDMMC peripheral and the bus transceivers hung on the socket, and some NUCLEO-H743ZI with microSD sockets hung off them. I was having data transfer issues with the H7 (perhaps DMA settings) on the port over the weekend so moved back to the F4 as we both had similar hardware. Tend to juggle targets when not making progress, the battle is fought on may fronts.

I'm leaning to having a "#define EMMC" instead of the stupidity of forking the entire drivers into separate SD and MMC trees. The state of the drivers across the families doesn't seem well synchronized, which is frustrating.

Nemui's code supports both SD and (e)MMC on the fly, no #defines needed. It's not hard to integrate it with the standard ST HAL layer below, and the standard ChaN FatFS layer above, for any STM32 of your choice.