Problem with FatFs and STM32Cube_FW_F7_V1.6.0 (Possible STM32Cube Bug)

Lori B. · ‎2017-01-30

Posted on January 30, 2017 at 15:59

Hi all! I'm trying to interface a STM32F7 with an 32 GB SDHC card, using the latest firmware libraries.

I'm using a STM32f746G DISCO and I started from the project under STM32746G-Discovery/Appllications/FatFs/FatFs_uSD..

I wrote a simple function and I executed it in the main after linking the driver and mounting the disk, to test reliability. The function is the following, where I write 1000 files in a loop..

ErrorStatus Test(void) { FIL MyFile; FRESULT res;  uint32_t byteswritten;  TCHAR StringPath[100] = {0};  cont=0;  while(cont < 1000) { sprintf((char*)StringPath,'File%d.fil', cont);  res = f_open(&MyFile, StringPath, FA_CREATE_ALWAYS | FA_WRITE); if(res !=FR_OK) return ERROR;  res = f_write(&MyFile, (void*)TempBuffer, sizeof(TempBuffer), (void *)&byteswritten); if((byteswritten == 0) || (res != FR_OK)) { return ERROR; }  f_close(&MyFile);  cont++; }  return SUCCESS; }�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?

TempBuffer is a global uint8_t buffer of size 51

The problem is that after correctly writing some files, f_write returns 'FR_DISK_ERR' and I can't understand why..

Decreasing the buffer's size seems to allow a bigger number of files to be written before the error, but it doesn't solve it...

Actually the problem is part of a much bigger project, but since I'm trying to understand what's wrong, I'm trying to keep things as simple as possible. That's why I took a STM32Cube project and left it untouched apart from the function I wrote.. But I really can't get the point of this problem anymway..Any idea?

I'm not using DMA, nor SD peripheral interrupt (as in the example).. The file ffconf.h is left untouched with_USE_LFN = 0, _USE_STRFUNC=2,_MIN_SS=__MAX_SS=5. Systick priority is as low as possible (0x0F)..

#sd #fatfs #sd-card #stm32f7 #stm32 #stm32cube

Note: this post was migrated and contained many threaded conversations, some content may be missing.

Lori B. · ‎2017-01-30

Posted on January 30, 2017 at 17:41

An update: the exact same project starting from STM32Cube_FW_F7_1.5.0 seems to work like a charm..

The problem could possibly come from the last version of STM32Cube.. I'll be investigating more in detail..

Nemui Trinomius · ‎2017-01-30

Posted on January 31, 2017 at 01:21

Dear lori.b,

I prefer to use V1.5.0's sd HAL driver because I have same problem as yours.

On the other hand,signal integrity may impacts Read/Write stability.

I met sometimes R/W fail several SDCard on STM32F746G-Discovery,

So I insert series-resister(22~47ohm/1005size) in SDMMC_CK line.

It improves signal stability by matching impedance.

Best Regards,

Nemui.

Lori B. · ‎2017-01-30

Posted on January 31, 2017 at 07:45

Hi Nemui! This is not the first time we have the same problem on this forum, as far as I remember

Thank you for your feedback and tip.. Sadly it's not so easy for me to modify my costum design..

It would be great to hear from ST about this, since they announced they rewrote and fixed the driver with version 1.6.0, but actually it looks like they messed it up..

Nor Sch · ‎2017-01-31

Posted on January 31, 2017 at 17:23

You should debug a little bit deeper to get the real Problem from FatFs. The 'FR_DISK_ERR' is a not really helpful catchall for different Problems. I know this Error from the typical Problem 'SD_RX_OVERRUN', which also can happen in f_write() because you have to read also some FS-Stuff. If this is the Reason, you should try to get the DMA running or change the SDMMC-Clocking. In this special Case maybe the Thread

https://community.st.com/0D50X00009XkeCzSAJ

with all the good Comments could help you.

The newer HAL should be prefered, so try to get it running

Lori B. · ‎2017-01-31

Posted on January 31, 2017 at 17:53

Hi sch.nor, thanks for your reply!

Obviously I spent a lot of time trying to debug it! I don't get an SD_RX_OVERRUN but an error code =08 (HAL_SD_ERROR_DATA_TIMEOUT).. And even drastically increasing the maximun acceptable timeout value doesn't help.

The point is that something very simple that works fine with FW_1.5.0 doesn't work anymore with FW_1.6.0.. So this really looks like an ST's problem and I think it's their to solve..

For now I switched back to V_1.5.0 in my project and everything is ok again.. I will deeply test the new version when it will eventually come out, before considering to upgrade to it..

Nor Sch · ‎2017-01-31

Posted on January 31, 2017 at 18:02

Just an Idea and not sure if it helps: delete the Error after it occures and than try further f_write() or other FS-Commands. Maybe it works again, maybe you will directly get again the Error. Next Step would be to reinit the SDMMC-Interface and the FatFs. I know it from the L4 that it is possible to hang the SDMMC-HW away and after that it's not possible to get the SDMMC back to work without a HW-Reset of the MCU.

Nemui Trinomius · ‎2017-01-31

Posted on February 01, 2017 at 04:28

Dear Lori B.

I updated my STM32F7 FatFs example projects to CubeF7v1.6.0.

http://nemuisan.blog.bai.ne.jp/?eid=192848#STM32F7

But I avoid using newest SD HAL Driver(stm32f7xx_hal_sd.c v1.2.0).

Instead, I implement original sdmmc driver based on old CubeF7v1.5.0.

It works pretty well on my F769I and F746G-Discovery(also SD HighSpeed Mode),

and attached pre-built binary for F746G-Discovery.

If you like,plz try this.

Best Regards,

Nemui.

________________

Attachments :

binary_for_F746G-Disco.7z.zip : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006HyyB&d=%2Fa%2F0X0000000bEX%2FSSmQ91ltf0ss7QJNVUKX9p_afbOM15YycjOMNzrYsjI&asPdf=false

Gid Rid · ‎2017-02-09

Posted on February 09, 2017 at 16:05

Hi Nemui,

I have been trying your code and found that it doesn't correctly identify some eMMC cards. Assuming that all high capacity cards will be 'sector' access only is not a valid method to detect an MMC card greater than 2GB. eMMCs can have the CMD1 'SEND_OP_COND' response bit 30 set low as this indicates 'byte', not 'sector', access. The correct method is to check if the CSD C_size is set to 0xFFF.

HAL_SD_ErrorTypedef SD_PowerON(SD_HandleTypeDef *hsd)

{

...

/*!< Send CMD1 to receive the contents of the Operating Conditions Register */

...

if (response &= SD_HIGH_CAPACITY)

{

hsd->CardType = HIGH_CAPACITY_MMC_CARD;

}

else

{

hsd->CardType = MULTIMEDIA_CARD;

}

Regards,

Gideon

Nemui Trinomius · ‎2017-02-13

Posted on February 14, 2017 at 01:32

Dear Gid Rid,

Thanks for your notice.

Surely I was wrong in Block/Byte access detection on MMC/eMMC initialization.

Former code can miss-detect and assume to ''block'' addressing in spite of ''byte''.

Byte addressing 4GB MMC/eMMC cards applied this.

I already fixed this routine refer to Samsung's apprication note.

For detail,see attached png.

Best Regards,

Nemui.