STM32Cube_FW_F7_V1.5.x USB-MSC Example bug(Calculation Overflow)

[Nemui Trinomius]

Posted on December 28, 2016 at 16:44

I found seriously bug on CubeF7 v1.5.0/v1.5.x

Bug found at ./STM32Cube_FW_F7_V1.5.0/Middlewares/ST/STM32_USB_Device_Library/Class/MSC/Inc/usbd_msc.h

diff -urN b/usbd_msc.h a/usbd_msc.h

--- b/usbd_msc.h 2016-09-14 17:48:24 +0900+++ a/usbd_msc.h 2016-12-29 00:37:02 +0900@@ -101,7 +101,7 @@ uint16_t scsi_blk_size; uint32_t scsi_blk_nbr;- uint32_t scsi_blk_addr;+ uint64_t scsi_blk_addr; uint32_t scsi_blk_len; } USBD_MSC_BOT_HandleTypeDef;'scsi_blk_addr' is also used sector-to-byte address exchange calcuration.But that causes data corruption above 4GB address datas.

I found this bug when implementing USB-SDCard Reader on STM32F746G-Discovery.

I suspect that exists similar bug on USB-Libraries.

Please fix this bug until next release.Best regards,Nemui.

[Imen.D · Accepted solution]

Posted on December 31, 2016 at 08:49

Dear

Nemui.Trinomius

‌,

Thanks forhighlighting this issue.

We will check internally this case and

we will keep you informed about the taken actions/explanation if needed.

We apologize for any inconvenience this may cause and thank you for your understanding.

All your feedback are welcome in order to improve our solutions.

Happy New Year

Best Regards

Imen

[Tesla DeLorean]

Posted on January 04, 2017 at 03:17

Over the years this has been frustrating. The real crux of the problem is the insistence somewhere within ST to represent byte offsets, and convert back and forth between byte and block numbers. A BLOCK device doesn't need to know about byte offsets, and a 32-bit block address can span 2TB worth of 512 byte blocks/sectors. The use of 64-bit variables isn't necessary for the Block IO functions, with some limited 64-bit maths needed for the capacity computations.

[marcopiovesan9]

Posted on August 03, 2017 at 10:55

Hi Imen, 

with STM32Cube FW_F7 V1.7.0 I am facing the same problem.

I was quite direct to change

scsi_blk_addr type  to uint64_t.

The problem is that CubeMX restore the uint32_t at next code generation.

Can you kindly suggest a workaround for avoiding this ?

Ciao

Marco