Never have been able to get FATFS working from STMCube.

[Waller.George]

Posted on April 23, 2016 at 22:53

Hi there,

I would appreciate any help here!

I have been trying to get FATFS working on the STM32F4 micro controllers for quite a while now but have never been able to get it to work. I have stepped through the code and have had different errors though time however to latest one is saying the disk is not present or a hard fault when the drive is to be initialised. I'm using the STM32F429ZIT6 on a custom board debugging with the STM32F4 discovery board. I have also used this discovery board and a different SD card to test the software but it still doesn't work. I have read through the code example in the STMCube FATFS manual however that didn't work either - I had to change the example code just to get the volume mounted. I have the pins of the micro controller directly connected to the SD card without pull-ups/downs.

Any advice would be greatly appreciated!

#je-ne-l'aime-cube #no-hablo-hal

[Waller.George]

Posted on April 26, 2016 at 11:27

Hi there thanks for this. I've tried copying the settings you've used for FATFS, SDIO and DMA and then edited the sd_diskio file however it still doesn't work. This time I'm unable to find out why as I get the end of the function 'HAL_SD_ReadBlocks_DMA' with 'errorstate = SD_OK' (no other errors up to here either) and when I step to return this value my program just ends up in the while loop at the end of the main function.

Would you mind sharing the FatFs code you used for your 'main'? It may have something to do with that. Also, would you mind having a look at my configuration in STMCube? Thanks! ________________ Attachments : fat_fs_dma.ioc : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006HtmQ&d=%2Fa%2F0X0000000aWo%2FNtfQF4iZ7aLprmA94iIBkoKBRCz5uxCrRYjxb0AJTY4&asPdf=false

[markb]

Posted on April 26, 2016 at 11:52

Hi,

Here's how I initialise the SD card:

void mountSDCard(int reportSectors) {
FRESULT res;
if((res = f_mount(&SDFatFS, ''0'', 1)) != FR_OK) {
printf(''Error: failed to mount SD card (%d)

'', res);
}
else {
sdCardMounted = 1;
printf(''Mounted SD card

'');
HAL_SD_ErrorTypedef hse;
hse = HAL_SD_WideBusOperation_Config(&hsd, SDIO_BUS_WIDE_4B);
if(hse != SD_OK) {
printf(''Error: failed to set SD card to 4 bit transfers (%d)

'', hse);
}

if(reportSectors) {
FATFS *fs = &SDFatFS;
DWORD fre_clst;
if((res = f_getfree(''0:'', &fre_clst, &fs)) != FR_OK) {
printf(''Error: failed to get free clusters (%d)

'', res);
}
else {
/* Get total sectors and free sectors */
DWORD tot_sect = (fs->n_fatent - 2) * fs->csize;
DWORD fre_sect = fre_clst * fs->csize;
/* Print the free space (assuming 512 bytes/sector) */
printf(''

%5lu MB total drive space.

%5lu MB available

'', tot_sect / 2048, fre_sect / 2048);
}
}
}
}

I will look at your configuration later (busy now). Cheers, Mark

[Tesla DeLorean]

Posted on April 26, 2016 at 22:43

If you decide you want to sanity check the hardware, the thread cited by stm32forum earlier points to another thread where I provide Ahmed with a .HEX capable of testing the card interface via the SWV viewer in the ST-LINK Utilities.

If you don't have the SWO (PB3) pin wired up, or have a preferred USART for console output, I can modify the test code to fit.

[Waller.George]

Posted on April 27, 2016 at 19:55

Thanks I would like to do that.

I had the 48MHz clock setup as 45MHz so I thought this maybe the issue. I changed it to 48MHz and made the main clock frequency quite a bit lower (didn't care just for testing). It worked!!! Then I changed the main clock to as high as I could get it while maintaining the 48MHz but it doesn't work again! It doesn't work with the lower system clock either! I've been reading the documentation for the SDIO peripheral and general info for the clock settings but nothing seems to tell me I'm doing it wrong.This is my current setup: Is this okay?  RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSI;  RCC_OscInitStruct.HSIState = RCC_HSI_ON;  RCC_OscInitStruct.HSICalibrationValue = 16;  RCC_OscInitStruct.PLL.PLLState = RCC_PLL_ON;  RCC_OscInitStruct.PLL.PLLSource = RCC_PLLSOURCE_HSI;  RCC_OscInitStruct.PLL.PLLM = 8;  RCC_OscInitStruct.PLL.PLLN = 168;  RCC_OscInitStruct.PLL.PLLP = RCC_PLLP_DIV2;  RCC_OscInitStruct.PLL.PLLQ = 7;  HAL_RCC_OscConfig(&RCC_OscInitStruct);  HAL_PWREx_EnableOverDrive();  RCC_ClkInitStruct.ClockType = RCC_CLOCKTYPE_HCLK|RCC_CLOCKTYPE_SYSCLK|RCC_CLOCKTYPE_PCLK1|RCC_CLOCKTYPE_PCLK2;  RCC_ClkInitStruct.SYSCLKSource = RCC_SYSCLKSOURCE_PLLCLK;  RCC_ClkInitStruct.AHBCLKDivider = RCC_SYSCLK_DIV1;  RCC_ClkInitStruct.APB1CLKDivider = RCC_HCLK_DIV4;  RCC_ClkInitStruct.APB2CLKDivider = RCC_HCLK_DIV2;  HAL_RCC_ClockConfig(&RCC_ClkInitStruct, FLASH_LATENCY_5);

[Tesla DeLorean]

Posted on April 27, 2016 at 22:27

The SDIO peripheral is rated at 75 MHz, it is normally clocked at 48 MHz based on the fact that USB, and the CRYPTO/HASH units want that. This comes off the Q-tap of the PLL, and the PLL must be running for the SDIO to function. This can catch you out if the HSE doesn't start, on the standard SPL template this would fail through and leave the part clocking from the HSI, and the PLL not started.

The BYPASS mode (DIV1) does not function correctly, so the bus speed is always half that (DIV2), typically 24 MHz, or 400 KHz during card initialization, and most MicroSD card would be rated to 50 MHz

[childresss]

Posted on May 10, 2016 at 04:09 STM32F415 here. SDIO to SD card working fine. No changes needed to code produced by CubeMX nor in the HAL Libraries. MCU runs at 64MHz. (speed-up to 128MHz to do compute intensive things). ==== Why? Is this forum's software so hosed up? VERY slow from the US, with my 100Mbps download speed.   This thread forces FireFox and IE to have a page about 3000 pixels wide. Horizontal scroll bar needed to see. No other web site does that. FIX IT!  

[Tesla DeLorean]

Posted on May 10, 2016 at 04:18

It's the broken Microsoft platform choosing to auto-width based on the max line length of one of the .IOC files posted in a ''Format Code Block'' window.

The only hope is that it will be replaced, because it's probably unfixable.