2017-09-08 03:21 PM
Function f_write doesn't work correctly to write on SD card. Actually it calls a series of other function and one of them is HAL_SD_WriteBlocks which puts the mcu into
Default_Handler:
Infinite_Loop: b Infinite_LoopThis is the code I have used to write a test string into a file:
FATFS fs;
FIL file;
uint8_t string[]='string';
UINT counter;
if(f_mount(&fs,SD_Path,1)==FR_OK){
if(f_open(&file,'root_f1',FA_WRITE|FA_CREATE_ALWAYS)==FR_OK){
f_write(&file,string,(UINT)sizeof(string),&counter);
}
}
f_close(&file);
f_mount(NULL,'0:',1);�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?
I have tried enabling and disabling every interrupts or DMA, changing sd clock, bus width. Does not make difference.
This is while reading from the SD Card works.
CubeMX ver: 4.0
CubeF7 ver: 1.7.0
MCU: STM32F746
#bug #stm32 #fSolved! Go to Solution.
2017-09-14 09:28 AM
I agree, I'm not sure it's a HAL issue. What I'm saying is that with the new HAL, the SDIO/FatFS seem to be less stable than before. In my case, with the following 2 changes the writing to the SD card works fine:
In my opinion, those changes as well as the ones reported by other users should not impact the SD wrinting functionality. This is why I have a bad feeling about the robustness of the HAL/FatFS combination.
2017-09-14 09:40 AM
Consider if your stack is large enough for the structures you are allocating on it. Does it fault if it is a static auto/local variable? How big is the stack, and how much of it is being used.
Look specifically at what is faulting, the CPU is capable of generating a lot of useful information about how/why it ended up there, a while(1) loop isn't going to be very informative.
2017-09-14 01:23 PM
Merci !!! That was really helpful. I have placed FIL and FATFS outside of main function and as global and now it works!
Of course in my case, I had to place both of these declarations as global, not just FIL .