2024-01-23 07:00 PM
I am currently trying to get an SD card working with SPI on an STM32L4R5ZI Nucleo board, using STM32CubeIDE V1.13.2 using the latest L4 embedded package.
I currently have my code opening the card and even opening the file (I receive FR_OK for both, even tested with invalid directories/files to verify they fail with the incorrect data). However, when I try to read from the SD card, I receive FR_INVALID_OBJECT code, which seems to be described here:
FR_INVALID_OBJECT
The file/directory object is invalid or a null pointer is given. There are some reasons as follows:
It has been closed, or the structure has been collapsed.
It has been invalidated. Open objects on the volume are invalidated by voulme mount process.
Physical drive is not ready to work due to a media removal.
I have tried changing SD card formats (originally on a 128GB FAT32 SD card and then to a 32GB exFAT formatted card), as I had read FATFS can have issues with FAT32. I do have FS_EXFAT enabled in the options.
With the f_mount and f_open commands, I can see the SPI commands being sent across on my scope, so I know it's communicating at the very least. With the f_read command, no SPI commands are being set. It seems to be setting the invalid object on this line of f_open:
FRESULT f_read (
FIL* fp, /* Pointer to the file object */
void* buff, /* Pointer to data buffer */
UINT btr, /* Number of bytes to read */
UINT* br /* Pointer to number of bytes read */
)
{
FRESULT res;
FATFS *fs;
DWORD clst, sect;
FSIZE_t remain;
UINT rcnt, cc, csect;
BYTE *rbuff = (BYTE*)buff;
*br = 0; /* Clear read byte counter */
res = validate(&fp->obj, &fs); /* ERROR RETURNED ON THIS LINE - Check validity of the file object */
Is it failing before it's even tried communicating with the chip? I'm not sure. Currently, my main code is pretty basic so I'll just post it here for reference:
FATFS FatFs; //Fatfs handle
FRESULT fres; //Result after operations
FIL test_file;
uint16_t bytes_read = 0;
uint16_t numBytes = 4096;
// uint8_t in_byte_array[numBytes] = {0};
uint8_t in_byte_array[4096] = {0};
char test_file_fn[256] ="";
sprintf(test_file_fn, "abcd.txt");
HAL_Delay(500);
fres = f_mount(&FatFs, "", 1);
fres = f_open(&test_file, test_file_fn, FA_OPEN_EXISTING | FA_READ);
fres = f_read(&test_file, &in_byte_array, 4, &bytes_read);
Let me know if there's anything else you'd recommend checking or if I'm missing something obvious. I think I'm pretty close to getting this working but have been struggling to find a solution for this and thought I'd check here to see if anyone has any advice. Thanks!
2024-01-23 08:26 PM
Make sure to clear auto/local variables and structures.
2024-01-24 03:35 PM
Sorry, I'm not entirely sure I understand what you're referring to regarding local variables/structures. Are you referring to the buffers I'm filling?
I was working on this a bit more today, took a few different approaches but I did go back to some old code I had that was writing to an SD card on a different board. I verified I could write data to the board without issue and that the code was working as expected. It looks like that code is able to mount, open, and write to the SD card but the same issue exists when trying to use the f_read command, so I'm not sure what the problem is.
I know STM uses V12C of the FATFS library but I don't see any glaring issues in the change notes (and I can't be the first person who has tried using f_read). I must be doing something wrong but I can't seem to see the issue. I've tried building it a couple different ways (using different diskio/app_fatfs approaches) but the end result seems to be about the same. Any idea what I might be doing wrong? Is it staring me in the face and I'm looking right past it? I have to think it's not a library related issue or we'd see a lot more posts on the board about it.
Thanks for your help!
2024-04-22 08:32 AM
Hi @JayDev
I have exactly the same issue with my STM32H747I-DISCO. My code was working a few days ago, and not anymore. Even if I add the initializing line code (f_mkfs(mySDPath, FM_ANY, 0, workbuffer, sizeof(workbuffer))), it doesn't work.
@Tesla DeLorean could you please give more details to what you mean with your answer: "Make sure to clear auto/local variables and structures."? Thank you so much!
2024-04-22 08:51 AM
'auto' variables are local variables (ie, those declared within functions) that are not declared 'static'
These are created on the stack and, unlike variables declared outside functions, they are not cleared when created - therefore they will have whatever junk happened to already be in those RAM locations.
Hence it is important to ensure that your code clears these variables before using them - or, at least, assigns valid values to them.
2024-05-20 11:19 PM
I had the same problem. I changed the USER_status function in the user_diskio.c file and everything worked. The function body had Stat = STA_NOINIT, I changed it to Stat = 0.
2024-05-23 10:53 PM
I ended up doing something similar to bypass the error (modifying the function validate in ff.c). But I don't feel it's right since we are changing a source code in a library that should work. I see so many people using the fatfs library and that don't seem to have this problem.
2024-05-23 11:20 PM