Skip to main content
michaelisaev9
michaelisaev9
Associate II
February 8, 2016
Question

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

  • February 8, 2016
  • 4 replies
  • 958 views
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
This topic has been closed for replies.

4 replies

markb
markb
Associate III
February 8, 2016
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
michaelisaev9Author
Associate II
February 8, 2016
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. 

Tesla DeLorean
Tesla DeLorean
Guru
February 8, 2016
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 VenmoUp vote any posts that you find helpful, it shows what's working..
Terms & ConditionsAccessibility statement