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

[michaelisaev9]

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

[markb]

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.

[markb]

Posted on February 08, 2016 at 08:57

https://my.st.com/public/STe2ecommunities/mcu/Lists/STM32Java/Flat.aspx?RootFolder=https://my.st.com/public/STe2ecommunities/mcu/Lists/STM32Java/STM32Cube%20library%20bug%20and%20config%20requests&FolderCTID=0x01200200770978C69A1141439FE559EB459D758000F9A0E3A95BA69146A17C2E80209ADC21&currentviews=73

[michaelisaev9]

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]

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.