cancel
Showing results for 
Search instead for 
Did you mean: 

SDIO BUG: Large SDHC file system corruption (sd_diskio.c)

michaelisaev9
Associate II
Posted on February 08, 2016 at 05:05

I found incorrect code in SD_write andSD_read code (sd_diskio.c). This conversion will fail on sectors above8388608 (4GB):

(uint64_t) (sector * BLOCK_SIZE)

It should be

(uint64_t) sector * BLOCK_SIZE

(uint64_t) sector * BLOCK_SIZE

(uint64_t) sector * BLOCK_SIZE

It should be #sdio #sd_diskio #cubemx #sdio
4 REPLIES 4
markb
Associate II
Posted on February 08, 2016 at 08:34

Yes, I reported this about a year ago. ST just don't care about the bugs. If it wasn't for git, this software really would be completely unusable.

michaelisaev9
Associate II
Posted on February 08, 2016 at 16:03

Hi, Mark!

I read your post. Another thing about SDIO DMA transfers is that CubeMX not only should give that as a setting, but it should correctly set Preemption priorities, as DMA Handler can deadlock waiting for SDIO Handler to set completion flag.

And about RTC - yes, it's silly to reset date/time in initialization code as RTCs are 99% battery backuped. 

Posted on February 08, 2016 at 17:58

I've never quite understood ST's need to convert block numbers into 64-bit byte offsets, and all the unnecessary back-and-forth that requires, along with all the issues of casting/scope that seem to be ignored. All the examples I've furnished keep blocks in 32-bit, and support up to 2TB. There is no need for all the excursions with the math, and the block devices, well, want block addressing.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..