USB Mass storage - using ST Mass_Storage example code

infoinfo988 · ‎2011-08-15

Posted on August 15, 2011 at 13:32

Hi,

I'm trying to implement USB mass storage and mass storage bootloader on STM32F103RBT but ...

I have a problem with the adapted the code from STM32_USB-FS-Device_Lib_V3.3.0 Mass_Storage example.

The ISTR_RESET interrupt is received (MASS_Reset() gets called) when I connect the USB cable to a host PC but no other USB interrupts take place.

I think that the code is correctly implemented:

- Peripiheral clock is enabled and Interrupts are enabled

- USB clock initialised to 1.5 of system clock of 72Mhz (checked that sys clock is 72Mhz)

The startup code calls the following routines:

MAL_Config();

Set_USBClock(); //USB clock setup

USB_Interrupts_Config(); /NVIC setup

USB_Init();

Has anyone implemented USB mass storage successfully? What interrupts would you expect to receive after ISTR_RESET?

Thanks.

infoinfo988 · ‎2011-08-15

Posted on August 16, 2011 at 00:19

Problem: Receiving only USB_ISTR Reset message and no other USB interrupts

Resolution: Add a 1.5K pull-up to D+

infoinfo988 · ‎2011-08-16

Posted on August 16, 2011 at 14:33

The original post was too long to process during our migration. Please click on the provided URL to read the original post. https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006I6aK&d=%2Fa%2F0X0000000brD%2FNiLeBjBU5zqHLp1EMy_7ueoM2cHaK22aH9CmceZO25w&asPdf=false

tsuneo · ‎2011-08-16

Posted on August 16, 2011 at 16:24

Maybe, your debug output disturbs the firmware from responding to the host in time. Switch off all the debug output, temporarily.

Host expects that the device responds to control transfers in time. The minimum timeout is 50 ms. If your debug output delays the device response, it causes timeout on the host side.

As you are starting from ST example, the USB stack should work 🙂

For MSC-BOT (Mass-Storage Class, Bulk-Only Transport), the timeout of bulk IN/OUT endpoints is much longer (around 5 sec) than Control transfer. You may add the debug output to the bulk IN/OUT process, but not for the control transfer process.

Tsuneo

infoinfo988 · ‎2011-08-16

Posted on August 16, 2011 at 20:52

Thanks Tsuneo, that's a great tip!

Usually I try to understand the inside workings before trying out something more complex (as it normally just doesn't work out of the box). But in this case it did work altogether!

I've turned off the tracing in usb_core.c, usb_isr.c and usb_int.c but left the tracing in mass_mal.c. This was fixed the time outs and it seems that the correct calls are now made to the Mass_Storage functions.

It's interesting to see that the example STM code is not handling CNTR_SOFM and CNTR_ESOFM but only CNTR_CTRM and CNTR_RESETM.

The plan now is to hopefully expose the on-board flash and other features of the system via the file system calls.

Here is the trace that's now generated at the mass_mal level (note that the calls to the actual read/write routines are not yet implemented):

Initialising USB

--> MAL_Init()

<-- MAL_Init()

--> MASS_init()

<-- MASS_init() - UNCONNECTED

##########################################

<-- MASS_Reset() - ATTACHED

#######--> MASS_Reset()

<-- MASS_Reset() - ATTACHED

######--> Mass_Storage_SetDeviceAddress() - Addressed

<-- Mass_Storage_SetDeviceAddress()

--> MASS_Data_Setup()

--> Mass_Storage_SetConfiguration() - CONFIGURED

<-- Mass_Storage_SetConfiguration() - ###########

<-- MASS_Data_Setup()

<-- Get_Max_Lun() 0

#--> MAL_GetStatus()

###--> MAL_GetStatus()

--> Mass_Storage_ClearFeature()