STM32F7 Cube Middleware bug SDcards > 4G

[James Murray]

The USB/MSC/SDcard middleware code does not work correctly beyond 4G due to a bug.

My code that is seeing the problem is based on an older version of Cube, but the ST code appears the same in the V1.12.0 cube code I downloaded today.

The SCSI protocol uses a 32bit block address and SDcard uses a 32bit _sector_ address. These work ok and do not have a problem beyond 4G. Unfortunately ST's code tries to convert these block numbers into byte address which causes an overflow (duh.)

The block size on SDcards is 512.

Middlewares/ST/STM32_USB_Device_Library/Class/MSC/Src/usbd_msc_scsi.c :

-----------

hmsc->scsi_blk_addr *= hmsc->scsi_blk_size; /* THIS OVERFLOWS 32bits */

-----------

Without rewriting that code, I believe it is a simple fix in

Middlewares/ST/STM32_USB_Device_Library/Class/MSC/Inc/usbd_msc.h

-----------

-- uint32_t                scsi_blk_addr; /* Code overflows this. */

++ uint64_t                scsi_blk_addr; /* Works correctly for >4G accesses */

 uint32_t                scsi_blk_len;

}

USBD_MSC_BOT_HandleTypeDef;

-----------

I made that change and now I can read and write beyond the 4G limit. It also means that the card works on Windows 10. Previously it would complain vigorously and when it offered to "fix" the card it actually wiped all the data.

James

PS. Not sure if this has been reported before, I did try searching.

[Tesla DeLorean]

ST has had issues with this for 10 years.

Why it even needs to be multiplied is the bigger question, it's a BLOCK address, not a BYTE address, and SCSI is dealing entirely with BLOCKS

#FFS​ 

[Tesla DeLorean]

I've generally dealt with these issues by fixing the underlying problem, not increasing the size of the number space, which results in a lot of unnecessary computation back and forth.

But issues with the BYTE offset nonsense has been recurrent for at least a decade and across multiple instantiations of the forum, and ST libraries.

There's code in some of the libraries that can't even keep the story straight across one source file, and compares apples to oranges on occasion.

[James Murray]

Agreed. My uint64_t fix is not ideal, but was successful in fixing the problem. That or a better fix needs applying to the HAL code.

Earlier today I tried to fix it better by changing that variable to actually mean blocks, but I F'd it up and the card didn't read... So I took the path of least resistance.

Looks like the Cube code hasn't been fixed to check for completion after SDcard reads/writes either. (Discussed on this forum MONTHS ago.)

James

[Amel NASRI]

Hello,

It is expected to deliver a fix for this issue in next STM32CubeF7 package that will embed a new version of STM32_USB_Device_Library. You should have it available on the web before the end of the year.

-Amel