MMC SPI Info

[fastlink30]

after a long time, i restart do test with mm-card, to do this i decide to use gfile (seems very simple to use), but i'm stuck on that

connected mmc to spi1, stmf4 discovery, em-blocks ide, ugfx 2.2, chibios 2.6.6

gfxconf.h:

GFX_USE_GFILE TRUE

GFILE_NEED_FATFS TRUE

mcuconf.h:

STM32_SPI_USE_SPI1 TRUE

/* Maximum speed SPI configuration (18MHz, CPHA=0, CPOL=0, MSb first).*/
static SPIConfig hs_spicfg = {NULL, GPIOA, 4, 0};
/* Low speed SPI configuration (281.250kHz, CPHA=0, CPOL=0, MSb first).*/
static SPIConfig ls_spicfg = {NULL, GPIOA, 4, SPI_CR1_BR_2 | SPI_CR1_BR_1};
/* MMC/SD over SPI driver configuration.*/
static MMCConfig mmccfg = {&SPID1, &ls_spicfg, &hs_spicfg};

.....

  // function alternate per spi1 
  palSetPadMode(GPIOA, 4, PAL_MODE_OUTPUT_PUSHPULL | PAL_STM32_OSPEED_LOWEST); // NSS
  palSetPadMode(GPIOA, 5, PAL_MODE_ALTERNATE(5) | PAL_STM32_OSPEED_LOWEST); // SCK
  palSetPadMode(GPIOA, 6, PAL_MODE_ALTERNATE(5) | PAL_STM32_OSPEED_LOWEST); // MISO
  palSetPadMode(GPIOA, 7, PAL_MODE_ALTERNATE(5) | PAL_STM32_OSPEED_LOWEST); // MOSI
  palSetPad(GPIOA, 4);// set NSS high

  mmcObjectInit(&MMCD1);
  mmcStart(&MMCD1, &mmccfg);

  GFILE *f;
  f = gfileOpen("config.cfg", "r");
  if (!f) {
        errmsg = "Err: Open WAV";
    } else {
      gfileRead(f,fbuff,20);
      gfileClose(f);
    }

i must use function mmcObjectInit() etc.? these are chibios functions. i looked in demo dir,demos/modules/gaudio/play-wave, nothing is initialized (how to choose what spi to use?), after prepare buffer, start to open file on card directly, i not understand how he know what spi use and how he initialize things.

Anyway in the piece of code i write up there, everytime f = 0 , if i leave mmc... functions or not, result is the same.

maybe i have forgot some step to make functional this?

there are only some few example about gfile.

thanks

[Joel Bodenmann]

Hello fastlink,

Similar to the GDISP and GINPUT module, the GFILE/FatFS module needs a "board file" to know how to talk to the device. This file is called "diskio.c" and we provide a standard one for ChibiOS/RT which you can find here: /src/gfile/gfile_fatfs_diskio_chibios.c. The easiest way is to modify the file so it matches your needs.

I have never tested it with MMC/SPI but I can guarantee you that it works just fine and out of the box with SDC/SDIO. So assuming that your peripherals are configured the right way it should just work out of the box for MMC/SPI as well.

This part does indeed need improvement in both, implementation and documentation. We will improve the diskio interface so you can either submit a custom file although you are using ChibiOS/RT or at least provide some macros to specify the used peripherals. However, it might take a while until I have time to do this as I want to roll out the beta of the uGFX-Studio first.

Please let us know when you need further help to get it working.

~ Tectu

[fastlink30]

gfile_fatfs_diskio_chibios,c is ok to use directly (without modification), if i have understood well, when i compile, i not have error or warnings.

if i debug the code the state of MMCD1 is BLK_ACTIVE, this means only that the driver is initialized only

when gfileOpen() try to mount the volume and arrive to disk_initialize function, the state is BLK_ACTIVE, so after all the things fail and can't open file

[Joel Bodenmann]

Did you ever manage to have it working just with ChibiOS/RT itself? The /src/gfile/gfile_fatfs_diskio_chibios.c is just a copy of the ChibiOS/RT file so assuming that your peripherals are all set up correctly it should work.

What is the return value of gfileMount() ?

~ Tectu

[inmarket]

I am not sure I am reading your problem correctly but I think you are saying that the gfxMount fails because the driver is already active and it tries to initialise it again.

If that is correct, look for where the driver is being previously initialised in your code and disable that piece of code. GFILE assumes that it is the one that is going to be initialising and controlling the block device driver

[fastlink30]

tectu, i have disabled gfile and 'installed' the chibios fatfs 0.9 patched, also i connected oscilloscope to spi out and signal is ok, but nss signal is not generated, is always high, and sure this is not good.

maybe is the sd-card module that not let pin a4 to go down becouse there are pull-up resistor on it.... 8-)

tomorrow i check

anyway i have unconnected the nss signal on the sd-card board but anyway signal not change state.

question: but the nss signal is drived by chibios/fatfs or not?

the test-code program is here to check signal out of spi, to check nss i have commented this line and used the 'standard' code to mount the fs

my initialization code

/* Maximum speed SPI configuration (18MHz, CPHA=0, CPOL=0, MSb first).*/
static SPIConfig hs_spicfg = {NULL, GPIOA, 4, SPI_BaudRatePrescaler_32};
/* Low speed SPI configuration (281.250kHz, CPHA=0, CPOL=0, MSb first).*/
static SPIConfig ls_spicfg = {NULL, GPIOA, 4, SPI_BaudRatePrescaler_128};
/* MMC/SD over SPI driver configuration.*/
static MMCConfig mmccfg = {&SPID1, &ls_spicfg, &hs_spicfg};

....

//   function alternate per spi1
    palSetPadMode(GPIOA, 4, PAL_MODE_OUTPUT_PUSHPULL | PAL_STM32_OSPEED_HIGHEST); // NSS
    palSetPadMode(GPIOA, 5, PAL_MODE_ALTERNATE(5) | PAL_STM32_OSPEED_HIGHEST); // SCK
    palSetPadMode(GPIOA, 6, PAL_MODE_ALTERNATE(5) | PAL_STM32_OSPEED_HIGHEST); // MISO
    palSetPadMode(GPIOA, 7, PAL_MODE_ALTERNATE(5) | PAL_STM32_OSPEED_HIGHEST); // MOSI
    palSetPad(GPIOA, 4);// set NSS high

    /*
     * Initializes the MMC driver to work with SPI1
     */
    mmcObjectInit(&MMCD1);
    mmcStart(&MMCD1, &mmccfg);

// test code
    for (i = 0; i < sizeof(txbuf); i++)
        txbuf[i] = (uint8_t)i;

    spiAcquireBus(&SPID1);              /* Acquire ownership of the bus.    */
    while (TRUE)
    {
        //palClearPad(GPIOD, GPIOD_LED5);     /* LED OFF.                         */
        spiStart(&SPID1, &ls_spicfg);       /* Setup transfer parameters.       */
        spiSelect(&SPID1);                  /* Slave Select assertion.          */
        spiExchange(&SPID1, 512,
                    txbuf, rxbuf);          /* Atomic transfer operations.      */
        spiUnselect(&SPID1);                /* Slave Select de-assertion.       */
    }
    spiReleaseBus(&SPID1);              /* Ownership release.               */

inmarket, as i write before, now i can't look becouse i have installed fatfs on chibios, anyway if i not have success in these days, i try to remount gfile and do what you suggest

[Joel Bodenmann]

Please make sure that one of the many examples that come with ChibiOS/RT using FatFS is working BEFORE you start using GFILE. The reason: For you it will be a lot easier to debug any issues.

If you have it working using one of the ChibiOS/RT examples it will be working with GFILE within minutes ;-)

A general suggestion: Always use SDIO/SDC instead of MMC/SPI mode (provided that your hardware setup allows it).

question: but the nss signal is drived by chibios/fatfs or not?

The NSS (chip select) signal is controlled by the ChibiOS/RT driver in either case (whether you are using GFILE or not). That is the reason why you have to set up your peripherals correctly (palSetPadMode() etc.).

~ Tectu

[fastlink30]

ok, switched to fats & chibios, sdio mode 1 bit, seems functional, fs is mounted correctly, not have more time for today.

next days i try re-implement gfile, if is all ok (sure yes) the next step is try to understand why spi mode not functioning.

thanks for support.

[Joel Bodenmann]

You can google a bit, there are many issues with using SPI with SD-Cards. SPI mode is not officially supported / included in the standard and it is often just some ugly implementation and these days barely any modern card even supports it at all. SDC is definitely the way to go (as you saw now ;-)).

Let us know about any results.

~ Tectu