USB host library MSC USBH_MSC_BOT_REQ_GetMaxLUN no response

[JDong.14]

My current application(STM32f777NI) is using USB host library for USB flash stick.

I am using stm32cubef7         V1.12.0, now the appellation is stack after call "USBH_MSC_BOT_REQ_GetMaxLUN", and it appears that the usb stick is not response for this command.

I have some search in USB spec: https://www.usb.org/sites/default/files/usbmass-ufi10.pdf

here is the exact word:

3.2.2

Logical Unit Number

The Logical Unit Number field specifies the Logical Unit that shall process the command block.

Even though

SFF-8070i

states that the Logical Unit Number (LUN) at the block (packet) level will be made

obsolete in a future standard, block level LUNs are used by UFI command blocks because a control level LUN

does not exist. (The control level LUN is set in the ATAPI Block Device Select Register, which does not exist

on the UFI device.)

If the UFI device supports only one logical unit, its Logical Unit Number shall be zero. For other than the

INQUIRY command, if the UFI device detects a unsupported Logical Unit Number, the device shall abort the

command, setting the sense key shall be set to ILLEGAL REQUEST and the additional sense code to

LOGICAL UNIT NOT SUPPORTED

It looks like it is perfect valid for a device not response for the USBH_MSC_BOT_REQ_GetMaxLUN command, I have remove the like, and found usb stick with the FAT FS is working now.

Is this is a bug in the library or I have missed anything?

[JDong.14]

/* Issue GetMaxLUN request */

status = USBH_MSC_BOT_REQ_GetMaxLUN(phost, (uint8_t *)(void *)&MSC_Handle->max_lun);

/* When devices do not support the GetMaxLun request, this should

be considred as only one logical unit is supported */

if((status == USBH_NOT_SUPPORTED) || (status == USBH_BUSY))

{

MSC_Handle->max_lun = 0U;

status = USBH_OK;

}

if(status == USBH_OK)

{

MSC_Handle->max_lun = (MSC_Handle->max_lun > MAX_SUPPORTED_LUN)? MAX_SUPPORTED_LUN : (uint8_t )(MSC_Handle->max_lun) + 1U;

USBH_UsrLog ("Number of supported LUN: %lu", (int32_t)(MSC_Handle->max_lun));

for(i = 0U; i < MSC_Handle->max_lun; i++)

{

MSC_Handle->unit[i].prev_ready_state = USBH_FAIL;

MSC_Handle->unit[i].state_changed = 0U;

}

}

Hightlight part is where I have made the change.

[iw2lsi]

thanks...

this works for me... I was experiencing the same problem on a STM32F746G-DISCO using CubeMX 5.1.0

Best Regards,

Giampaolo

[JDong.14]

It is turns out is my fault, The USB stack use heap, and my linker script have set heap size as 0, interestingly enough, there are no warning/error during the build.

After I have enable the heap, the stack works fine.

[iw2lsi]

Hi Ji.****...

that's really strange... because I have the heap enabled and in the past days I've also done several test with different memory layouts...

Below is my heap/stack status... which was not working until I apply your changes...

Giampaolo

/* Entry Point */
 
ENTRY(Reset_Handler)
 
 
 
/* Highest address of the user mode stack */
 
_estack = 0x20050000;  /* end of RAM */
 
/* Generate a link error if heap and stack don't fit into RAM */
 
_Min_Heap_Size = 0x2000;   /* required amount of heap */
 
_Min_Stack_Size = 0x800; /* required amount of stack */
 
 
 
/* Specify the memory areas */
 
MEMORY
 
{
 
RAM (xrw)   : ORIGIN = 0x20000000, LENGTH = 320K
 
FLASH (rx)   : ORIGIN = 0x8000000, LENGTH = 1024K
 
}
 
 
 

[JDong.14]

Have you set break point on USBH_malloc and USBH_free to see if the memory have been allocated in the correct address?

[iw2lsi]

Hi...

now I'm really confused... as it seems that there is really a malloc problem and in:

phost->pActiveClass->pData = (MSC_HandleTypeDef *)USBH_malloc (sizeof(MSC_HandleTypeDef));

as *phost->pActiveClass->pData = 0*... but it works... and files are

written and read in the right way...

Giampaolo

Il giorno mer 27 feb 2019 alle ore 10:31 ST Community ha

scritto:

[JDong.14]

I think it is maybe a happy coincident 🙂

[iw2lsi]

mmm...
by replacing malloc and free with the freeRTOS ones, memory is now correcly allocated (or maybe just correcly reported by the gdb)...
BUT:
there is no need for the changes in USBH_MSC_ClassRequest()
// if(status == USBH_NOT_SUPPORTED || (status == USBH_BUSY))
if(status == USBH_NOT_SUPPORTED))
only for the old Apacher stick... the new SanDisk ones
1st log:
HOST_USER_CONNECTION
USB Device Attached
PID: 5571h
VID: 781h
Address (#1) assigned.
Manufacturer : SanDisk
Product : Cruzer Fit
Serial Number : 4C530001200731116590
Enumeration done.
This device has only 1 configuration.
Default configuration set.
Switching to Interface (#0)
Class : 8h
SubClass : 6h
Protocol : 50h
MSC class started.
HOST_USER_CLASS_SELECTED
Number of supported LUN: 2
LUN #0:
Inquiry Vendor : SanDisk
Inquiry Product : Cruzer Fit
Inquiry Version : 1.00
MSC Device ready
MSC Device capacity : 1342176768 Bytes
Block number <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< stuck here w/o || (status == USBH_BUSY)) on SanDisk
2nd log:
HOST_USER_CONNECTION
USB Device Attached
PID: 5571h
VID: 781h
Address (#1) assigned.
Manufacturer : SanDisk
Product : Cruzer Fit
Serial Number : 4C530001200731116590
Enumeration done.
This device has only 1 configuration.
Default configuration set.
Switching to Interface (#0)
Class : 8h
SubClass : 6h
Protocol : 50h
MSC class started.
HOST_USER_CLASS_SELECTED
Number of supported LUN: 1
LUN #0:
Inquiry Vendor : SanDisk
Inquiry Product : Cruzer Fit
Inquiry Version : 1.00
MSC Device ready
MSC Device capacity : 1342176768 Bytes
Block number : 61341695 <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< works even w/o || (status == USBH_BUSY)) on Apacher
Block Size : 512
HOST_USER_CLASS_ACTIVE
application ready
APPLICATION_READY
file pippo.txt created
Best Regards,
Giampaolo

[JDong.14]

Try to increase heap size and try.

The first USB have 2 LUN, which means the first one will malloc twice.

Your working USB stick only have 1 LUN, maybe the heap size just enough to hold 1 LUN