2018-06-19 05:21 AM
Hi,
I've been dealing with the SD card problem since the CubeMX version 4.
Here are the corresponding parts of my code:
...
...
...
/* USER CODE BEGIN PV */
/* Private variables ---------------------------------------------------------*/ FATFS myFATFS = {0}; FIL myFILE; UINT testByte;/* USER CODE END PV */
...
...
...
/* USER CODE BEGIN 2 */
if(f_mount(&myFATFS, SDPath, 1) == FR_OK){ char myPath[] = 'WRITE1.TXT\0'; f_open(&myFILE, myPath, FA_WRITE | FA_OPEN_ALWAYS); char myData[] = 'Hello World\0'; f_write(&myFILE, myData, sizeof(myData), &testByte); f_close(&myFILE); HAL_Delay(1000); } /* USER CODE END 2 */...
...
...
Here, the problem is in f_mount, it doesn't go forward. Debugging further, the code stucks in 'ff.c' file at the following bold line (line 3050):
/* Find an FAT partition on the drive. Supports only generic partitioning rules, FDISK and SFD. */
bsect = 0;
fmt = check_fs(fs, bsect); /* Load sector 0 and check if it is an FAT-VBR as SFD */
if (fmt == 2 || (fmt < 2 && LD2PT(vol) != 0)) { /* Not an FAT-VBR or forced partition number */
for (i = 0; i < 4; i++) { /* Get partition offset */
pt = fs->win + (MBR_Table + i * SZ_PTE);
br[i] = pt[PTE_System] ? ld_dword(pt + PTE_StLba) : 0;
}
This problem continues in the last 4 version, and still not fixed. Can someone try to create a project from scratch with STM32CubeMX version 4.26 and FW F4 v1.21 which are both the lastest versions by the moment?
Here are few extra notes:
- I set minimum heap and stack size as 0x2000 and 0x4000.
- I'm using Keil uVision MDK v5.15 with compiler v5.05 update 2 (build 169).
- My operating system is Windows 7 Pro SP1 64 bits.
- I'm sure that there is no hardware issue as I was able to run the SD card with a example project.
Regards,
Ogulcan
#f_mount #stm32cube-fw_f4-v1.0 #cubemx-4.26 #fw_f4-v1.0 #sd-card #cubemx #stm32f4 #fatfs #sdcard-fatfs Note: this post was migrated and contained many threaded conversations, some content may be missing.2018-06-26 01:19 AM
Hi Jason,
I used the same code to the exactly same hardware, I only changed the versions. In CubeMX v4.21 + F4_FW V1.16 it worked and in CubeMX v4.26 + F4_FW V1.21 it did not work. How would you explain this?
2018-06-26 01:59 AM
Hi Jason,
Would you please make more explanation on how you increased the signal quality of SDIO_CLK on a standard Discovery board? Have you made any hardware patches on the board?
Best regards,
Mete
2018-06-26 04:11 AM
Dear Ogulcan,
OK.
Please don't worry. I am sure you can solve the issue too.
I also spent a lot of time because of 4-bit SDIO mode.
I will summarize all of my solution tomorrow.
Before I share my test result, I would like to prove my solution.
Please watch following video first. (
CubeMX v4.26 + F4_FW V1.21)
https://drive.google.com/open?id=17D2bvtGdE2OYBR91R5viRzacOCtCI8IS
Best regards,
Jason
2018-06-26 04:19 AM
2018-06-26 06:26 AM
Dear Jason,
Thank you for your explanation about the problem and its solution. Since you carry all the SDIO signal by wire it should be quite normal to have signal integrity problems. It would be much better to design a custom add-on PCB where all the signal integrity for high speed signals are supported.
Best regards,
Mete
2018-06-26 06:54 AM
Series resistors on short runs can reduce the ringing, 27 or 33 ohm would likely suffice. You can also reduce the slew rate on the pin.
2018-06-26 07:48 AM
Thank you for the advice.
Yes. You are right.
Of course custom PCB is strongly recommended for high speed signals.
But I am just studying STM32 evaluation board. And I am not a rich man.
Many of STM32 learners may have the same issue.
So I just hope my solution would be helpful for other STM32 users.
2018-06-26 07:53 AM
Thank you for the comment.
I really agree to your opinion. 100ohm is too high value for damping.
27 or 33ohm is more suitable for signal integrity.
But there was no 27ohm or 33ohm in my office today...
This is the reason why I used 100ohm.
Anyway thanks for your help.
2018-06-26 07:49 PM
Dear Ogulcan,
As I mentioned yesterday, I uploaded my source code about SDIO 4-bit mode.
Please refer to following github url.And you need to check following items one by one carefully.
1. H/W workaround should be applied to your board.
Series damping resistor can be a proper solution. 33ohm is recommended for series damping resistor. But optimized value can be different from each other.2. Please check SDIO signal integrity with oscilloscope.
3. Please adjust SDIOCLK clock divide factor
SDIO_CK = SDIOCLK / [CLKDIV + 2]. And then find a optimized divide factor yourself.Currently, CLKDIV is 6. So it runs at 6MHz speed.
And I added a HAL_Delay(10) code for more stable initialization during power on.
By the way, could you share the test result after you finish test with my S/W code?
Generally, most of people just take the solution.
They just take something and give nothing to other people.
Best regards,
Jason
2018-06-27 05:17 AM