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]

Hi...

increasing the heap (x2, now is 0x4000) did not help... it seems that:

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

is really making the difference in my case... I'll try to investigate it deeply...

Giampaolo