2016-04-23 01:53 PM
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-hal2016-04-24 03:58 AM
Okay now I have added the pullup resistors like in the STM324x9I-EVAL documentation however it still doesn't work. I get the error 'SD_CMD_RSP_TIMEOUT' which, I know, is self explanatory. This is happening on the code example for the STM324x9I-EVAL - I'm using the Application -> FatFs -> FatFs_uSD demo. I've disabled the SD card detect part of the code as I don't have that implemented in my hardware so the code doesn't check whether there is a card - it just assumes there is.
2016-04-25 07:53 AM
Hi,
What pin allocations do you have on your board for the SD card, card detect? Did you checked that SDcard is connected using the same pins that are configured in the software ? You can look at this , it may be helpful for you. Regards2016-04-25 12:15 PM
I've had a lot of success, with a lot of F2/F4 design using SD, SDHC and SDXC cards, but I'm not using, or interested in using, Cube/HAL. There are strong reasons for that, which will become increasingly apparent.
Most recently I've built high-speed loggers using GHIhttps://www.ghielectronics.com/catalog/product/535
andhttps://www.ghielectronics.com/catalog/product/474
boards, which don't have pull-ups in their design.2016-04-25 12:36 PM
Hi there,
I'm using:PC8 D0PC9 D1PC10 D2PC11 D3PC12 CLKPD2 CMDI used the default assignments from STMCube. I'm not using card detect or write protect.2016-04-25 01:37 PM
Looks pretty standard. Looking over the
https://www.ghielectronics.com/downloads/schematic/FEZ_Lemur_SCH.pdf
, there is a 10K pull-up on PC11 (DAT3/CS), one could configure something similar in the pin.2016-04-25 01:37 PM
I have set the PLL correctly I think. This is the code.
void SystemClock_Config(void){ RCC_OscInitTypeDef RCC_OscInitStruct; RCC_ClkInitTypeDef RCC_ClkInitStruct; __PWR_CLK_ENABLE(); __HAL_PWR_VOLTAGESCALING_CONFIG(PWR_REGULATOR_VOLTAGE_SCALE1); 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 = 180; RCC_OscInitStruct.PLL.PLLP = RCC_PLLP_DIV2; RCC_OscInitStruct.PLL.PLLQ = 8; HAL_RCC_OscConfig(&RCC_OscInitStruct); HAL_PWREx_ActivateOverDrive(); RCC_ClkInitStruct.ClockType = 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); HAL_SYSTICK_Config(HAL_RCC_GetHCLKFreq()/1000); HAL_SYSTICK_CLKSourceConfig(SYSTICK_CLKSOURCE_HCLK); /* SysTick_IRQn interrupt configuration */ HAL_NVIC_SetPriority(SysTick_IRQn, 0, 0);}2016-04-25 01:44 PM
I have tried adding 47k pull-ups to all lines other than the clock like on the 429-EVAL board however this doesn't work either!
2016-04-25 02:36 PM
2016-04-25 03:48 PM
Note that this code includes the fix for the bad cast bug that has recently been (re)reported.
That wouldn't even be needed except the unnecessary excursion into 64-bit byte offsets and back, with the MUL64 and DIV64 that entails, but that stems from 8 years of poor design, and propagation of that.