EEVblog Electronics Community Forum
Electronics => Microcontrollers => Topic started by: Boscoe on September 12, 2019, 07:24:27 pm
-
Hi all,
I've got a strange one here, perhaps something wrong with the STM32 HAL. I'm trying to demo FATFS that has been created through CubeMX. I have used SDIO 4 bits and enabled FATFS with the default settings. I use the code below to test. I can create the file on the disk however when I try to write to the file I get a Hardfault in the SDMMC_WriteFIFO function. The memory address for the data it's trying to write to the card is out of range at 0x20050000. I find this very strange. Has anyone else had this issue? I see one person has posted it on the ST forums without a proper solution.
Thanks
f_mount(&FatFs, "", 0);
fr = f_open(&Fil, "george.txt", FA_WRITE | FA_CREATE_ALWAYS);
if (fr == FR_OK)
{
f_write(&Fil, "It works!\r\n", 11, &bw);
fr = f_close(&Fil);
if (fr == FR_OK && bw == 11)
{
asm("NOP");
}
}
-
So the file is actually created on the SD card, you've verified this by reading it on a PC?
Tried with code optimizations disabled?
SD was formatted manually by you on PC to a compatible type, or with fatfs? Maybe look at the blocksize/filesystem/etc info, see if it matches up, I think there was a structure for that somewhere..
Fairly sure it doesn't matter, but could try FA_READ | FA_WRITE for permissions as well.
http://elm-chan.org/fsw/ff/doc/open.html (http://elm-chan.org/fsw/ff/doc/open.html)
http://elm-chan.org/fsw/ff/doc/mount.html (http://elm-chan.org/fsw/ff/doc/mount.html)
-
https://community.st.com/s/question/0D50X0000ARPK0mSQH/stm32cubemx-sdmmc-fatfs-code-is-broken-with-a-buffer-overrun-here-is-a-fix
?
-
Thank you both. I used the patch and got it working however have run into some other issues. Will be putting this on hold.
-
No problem and good luck.
I don't know if you're using a recent version of ST's library or not. If so, and the problem has not been officially fixed yet, I think this is really bad of ST.
This tells that you should usually NOT trust vendor's libraries (except maybe for the very low-level ones) and example code. They are often full of bugs and are just released "as is".
-
No problem and good luck.
I don't know if you're using a recent version of ST's library or not. If so, and the problem has not been officially fixed yet, I think this is really bad of ST.
This tells that you should usually NOT trust vendor's libraries (except maybe for the very low-level ones) and example code. They are often full of bugs and are just released "as is".
Yes they certainly have quirks however this is the first issue I've come across that is outright broken. Essentially the problem is you have to write a block even if you just want to right one byte. So you have your one byte to write and pass this as a pointer to the write function and the write function just keeps incrementing that pointer for one whole block size regardless of how much memory that pointer has been allocated!!!
-
Essentially the problem is you have to write a block even if you just want to right one byte. So you have your one byte to write and pass this as a pointer to the write function and the write function just keeps incrementing that pointer for one whole block size regardless of how much memory that pointer has been allocated!!!
Perhaps they have to write a whole block at a time as it's a block file system and not RAM ?
-
This is a bug in the FATFS code and not in SDMMC_WriteFIFO() itself.
SDMMC_WriteFIFO() takes a pointer to uint32_t. The parameter being a pointer is sort of misleading; it actually only copies the pointed 32-bit word to some register. This is why there is no additional "block length" parameter. The only acceptable way of using it is passing a pointer to uint32_t, pointing to a single uint32_t variable, or a buffer (array) of uint32_t's, from which it will only use the first word. Of course it could also be a buffer of bytes, as long as it's properly aligned and points to at least 4 bytes.
This is an instance of this function I got:
HAL_StatusTypeDef SDMMC_WriteFIFO(SDMMC_TypeDef *SDMMCx, uint32_t *pWriteData)
{
/* Write data to FIFO */
SDMMCx->FIFO = *pWriteData;
return HAL_OK;
}
Some developer adapting FATFS probably played tricks passing it a pointer to a buffer of bytes instead. Of course, if the pointed-to buffer has less than 4 bytes, it's a bug. If it's not aligned to a 32-bit word, it may also crash depending on the CPU. A basic misuse of pointers.