-
Notifications
You must be signed in to change notification settings - Fork 342
Description
I am using STM32Cube_FW_H7_V1.11.2 and found a bug in
\Middlewares\ST\STM32_USB_Device_Library\Class\MSC\Src\usbd_msc_scsi.c
that can cause read/write errors when using multiple luns of different sizes.
This is what happened ...
I was unable to open a text file on the LUN 0 drive after Windows had detected the LUN 0 and 1 drives.
I used WireShark and saw the following:
...
SCSI: Test Unit Ready LUN: 0x00
SCSI: Response LUN: 0x00 (Test Unit Ready) (Good)
SCSI: Test Unit Ready LUN: 0x01
SCSI: Response LUN: 0x01 (Test Unit Ready) (Good)
SCSI: Read(10) LUN: 0x00 (LBA: 0x00587bf0, Len: 1)
SCSI: Response LUN: 0x00 (Read(10)) (Check Condition) with Status: Command Failed (0x01)
...
I put several breakpoints in the SCSI_Read10 function and saw that SCSI_CheckAddressRange was failing because the hmsc->scsi_blk_nbr variable contained the number of blocks for LUN 1, not LUN 0.
The SCSI_Read10, SCSI_Read12, SCSI_Write10 and SCSI_Write12 functions are all using the hmsc->scsi_blk_size and hmsc->scsi_blk_nbr variables but those values can be wrong when using multiple luns of different sizes. Those functions should first update those values via a call to GetCapacity just like the SCSI_ReadCapacity10, SCCSI_ReadCapacity16 and SCSI_ReadFormatCapacity functions do.
I added the following code to the SCSI_Read10, SCSI_Read12, SCSI_Write10 and SCSI_Write12 functions and the issue was fixed.
if (((USBD_StorageTypeDef *)pdev->pUserData[pdev->classId])->GetCapacity(lun, &hmsc->scsi_blk_nbr, &hmsc->scsi_blk_size) != 0)
{
SCSI_SenseCode(pdev, lun, NOT_READY, MEDIUM_NOT_PRESENT);
return -1;
}
Metadata
Metadata
Assignees
Labels
Type
Projects
Status