cancel
Showing results for 
Search instead for 
Did you mean: 

WriteStatus not changing from 0 in f_mkfs function for FATFS and SDIO 4-bit.

Anonymaton
Associate II

This might sound familiar. I'm working on getting FatFS and SDIO-4 bit communication working. My evaluation board is a NUCLEOF411RE. The latest problem I've run into is on line 355 of sd_diskio.c, which it gets to from ff.c, line 5661 (shown below).

Anonymaton_1-1726000692590.png

 

Anonymaton_0-1726000614513.png

To summarize, WriteStatus isn't switching away from 0. The only function that can change WriteStatus to anything other than 0 is BSP_SD_WritecpltCallback, so clearly it isn't being called. I looked into it more and saw this post. Tried it, but still getting stuck at the same spot. Anyone have any clue what might be happening?

edit: I managed to trace my way back (somewhat) through what appears to be a chain of interrupts that I wasn't able to get into before, and things have just gotten more confusing. Screenshot 2024-09-10 163106.jpg

So disk_write goes to sd_write, which is where it gets hung up at the end. The SDIO IRQ Handler gets involved and then it's all downhill from there. The problem is that I can't seem to get a breakpoint to stop me where I want it to stop me so I can see more of what's going on. The only reason I found any of this was because I suspected that instead of calling the HAL_SD_TxCpltCallback in bsp_driver_sd.c, it was calling the one in stm32f4xx_hal_sd.c, so I put down a couple break points in the latter's versions to see if I could catch it entering the UNUSED function. Instead, as shown above, I got dumped into SD Error callback, which I didn't have a breakpoint in at the time (just retested to be sure; even without a breakpoint I get dumped in there).

edit 2: I've been trying to lay down breakpoints through the chain of events that seems to be taking place (as highlighted in the thread in the image above. No matter what I do though, it skips to that last spot in the HAL_SD_ErrorCallback function. 

I'll try to get a more detailed picture of the supposed chain of events getting this thing to where it is, but so far the breakpoints don't seem to matter. 

edit 3: Alright, I've made some progress, but I'm not really sure how to fix it. The program gets to stm32f4xx_hal_sd.c and goes fine until it gets to line 1624; an if condition that does this: 

hsd->ErrorCode |= HAL_SD_ERROR_DATA_CRC_FAIL;

I'm looking through st community and I'm seeing this as a recurring problem, but not seeing much for solutions. Have I missed something obvious?

 

 

 

1 REPLY 1
Anonymaton
Associate II

Okay, I might have found what's wrong, but I can't say for sure. It looks like the problem is the SD card. The errors seem to start piling up once I get to line 3013 of stm32f4xx_hal_sd.c, which checks "if((scr[1U] & SDMMC_WIDE_BUS_SUPPORT) != SDMMC_ALLZERO)". Basically, the program thinks that the sd card I'm using doesn't support wide-bus setup. I don't know yet if the card I'm using should support it, so I'm going to check that. Like I said before, I'm using a SanDisk Ultra 16GB microSDHC card I bought back in 2021.