cancel
Showing results for 
Search instead for 
Did you mean: 

reading form USB flash drive

bhosekarshilpa
Associate II
Posted on July 20, 2013 at 11:30

Hello all,

I

am a bit new to

ARM processors.

I want to read images from USB Flash drive

attached to STM32F4 Discovery.I used the USB

host library +FA

TFS.While debugging

I figured out that the device is not getting enumerated.i.e

,in the usbh_core.c from

HOST_DEV attached it goes to HOST_CTRL_XFER.

this is my main.c program:

int main(void)

{

    init_GPIO();

    USBH_Init(&USB_OTG_Core, USB_OTG_FS_CORE_ID, &USB_Host, &USBH_MSC_cb, &USR_Callbacks);

for(;;)

{

USBH_Process(&USB_OTG_Core, &USB_Host);

}}

The USBH state remains is shown b

elow:

    

{gState = HOST_CTRL_XFER, gStateBkp = HOST_ENUMERATION, EnumState = ENUM_IDLE, RequestState = CMD_WAIT, Control = {hc_num_in = 1 '\001',

    hc_num_out = 0 '\000', ep0size = 64 '@', buff = 0x20000634 '''', length = 8, errorcount = 0 '\000', timer = 0, status = CTRL_START, setup = {

      d8 = ''\200\006\000\001\000\000\b'', b = {bmRequestType = 128 '\200', bRequest = 6 '\006', wValue = {w = 256, bw = {msb = 0 '\000',

            lsb = 1 '\001'}}, wIndex = {w = 0, bw = {msb = 0 '\000', lsb = 0 '\000'}}, wLength = {w = 8, bw = {msb = 8 '\b',

            lsb = 0 '\000'}}}}, state = CTRL_SETUP_WAIT}, device_prop = {address = 0 '\000', speed = 1 '\001', Dev_Desc = {bLength = 0 '\000',

      bDescriptorType = 0 '\000', bcdUSB = 0, bDeviceClass = 0 '\000', bDeviceSubClass = 0 '\000', bDeviceProtocol = 0 '\000',

      bMaxPacketSize = 0 '\000', idVendor = 0, idProduct = 0, bcdDevice = 0, iManufacturer = 0 '\000', iProduct = 0 '\000',

      iSerialNumber = 0 '\000', bNumConfigurations = 0 '\000'}, Cfg_Desc = {bLength = 0 '\000', bDescriptorType = 0 '\000', wTotalLength = 0,

      bNumInterfaces = 0 '\000', bConfigurationValue = 0 '\000', iConfiguration = 0 '\000', bmAttributes = 0 '\000', bMaxPower = 0 '\000'},

    Itf_Desc = {{bLength = 0 '\000', bDescriptorType = 0 '\000', bInterfaceNumber = 0 '\000', bAlternateSetting = 0 '\000',

        bNumEndpoints = 0 '\000', bInterfaceClass = 0 '\000', bInterfaceSubClass = 0 '\000', bInterfaceProtocol = 0 '\000',

        iInterface = 0 '\000'}, {bLength = 0 '\000', bDescriptorType = 0 '\000', bInterfaceNumber = 0 '\000', bAlternateSetting = 0 '\000',

        bNumEndpoints = 0 '\000', bInterfaceClass = 0 '\000', bInterfaceSubClass = 0 '\000', bInterfaceProtocol = 0 '\000',

        iInterface = 0 '\000'}}, Ep_Desc = {{{bLength = 0 '\000', bDescriptorType = 0 '\000', bEndpointAddress = 0 '\000',

          bmAttributes = 0 '\000', wMaxPacketSize = 0, bInterval = 0 '\000'}, {bLength = 0 '\000', bDescriptorType = 0 '\000',

          bEndpointAddress = 0 '\000', bmAttributes = 0 '\000', wMaxPacketSize = 0, bInterval = 0 '\000'}}, {{bLength = 0 '\000',

          bDescriptorType = 0 '\000', bEndpointAddress = 0 '\000', bmAttributes = 0 '\000', wMaxPacketSize = 0, bInterval = 0 '\000'}, {

          bLength = 0 '\000', bDescriptorType = 0 '\000', bEndpointAddress = 0 '\000', bmAttributes = 0 '\000', wMaxPacketSize = 0,

          bInterval = 0 '\000'}}}, HID_Desc = {bLength = 0 '\000', bDescriptorType = 0 '\000', bcdHID = 0, bCountryCode = 0 '\000',

      bNumDescriptors = 0 '\000', bReportDescriptorType = 0 '\000', wItemLength = 0}}, class_cb = 0x20000084, usr_cb = 0x2000003c}

The

usb

h always re

mains at this.

Any leads on how to proceed form here shall be helpful.

#usb
15 REPLIES 15
Posted on December 16, 2013 at 17:08

The USB Peripheral is also clocked by the AHB (>30 MHz)

May be some engineers at EmBest can provide you with some insight, or ship me a board?

USE_STDPERIPH_DRIVER

STM32F4XX

USE_STM324xG_EVAL ??

USE_USB_OTG_HS

USE_ULPI_PHY

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
mail2
Associate II
Posted on December 18, 2013 at 20:31

Hi,

The Clocks are OK, i can measure the 60MHz Clock for the ULPI bus and i see activity on all ULPI bus lines. I have checked that all signals are connected and i have checked the power supplies. It seems that the STM32F4 can read the ULPI Registers sometimes, but it can never write to it. The STM gets - for example - a port interrupt when i connect a usb memory stick to the USB port. But on the other side the ULPI never rises the CPEN pin to switch the VBUS power on. Currently i have switched the VBUS line manually by a wire connection.

It seems to me that i have a timing problem on the ULPI bus. So i have checked the tracks on the PCB and see that there are different in their lengths. The clock line is the shortest track with something around 22mm. All other tracks are longer, between 30 and 44mm, D7 ist the longest track. Could this be a (the?) problem?

Martin

mail2
Associate II
Posted on January 11, 2014 at 20:50

After many tests, coding, measurements and so on

I can finally say: The USB3320 USB ULPI works with STM32F207 and STM32F407!

We have had a problem with the routing of the ULPI bus on our PCB (some pins where swapped) and it seems, that the USB3320 is very sensitiv to his supply voltages. When the reset line raises to early, then the ULPI doesn’t work with the STM32 any more. The STM32 gets an port interrupt, but then the communication is not stable any more.

Spend the reset line of the ULPI a dedicated signal, so that the STM32 can reset the ULPI while initializing it (then the supply voltages should be stable) and/or pull-up the ULPI STP Signal with an 2k2 resistor. Both solutions are working.

Martin

Posted on January 11, 2014 at 22:22

Thanks for the update, I think it will be very helpful for others here.

So if I had a 3V or 3.3V supply, with a POR thresholding at 2.7V, clamping RESET low for 100-200 mS after the threshold was reached, do you think that would be effective for the model of the 3320 you have created.

Is it the 1.8V to 2.7V region where it is sensitive?
Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
mail2
Associate II
Posted on January 11, 2014 at 23:52

Hello Clive,

Yes, i think that this threshold is effective. It seems that the 1.8V Domain is not the problem.

A dedicated reset signal from the controller to the ULPI seems to be the most flexible way to start the communication. Without this signal, the ULPI interprets some „startup noise signals“ as commands and stops any further communication. When there is no reset line available, a 2k2 pull-up resistor on the ULPI STP signal stops the ULPI after his own reset and allows the STM32 to initiate the communication by itself. 

My english is not good enough to describe this to everyone, but i can say: The USB3320 works with these controllers!

Martin

Posted on January 12, 2014 at 01:58

Don't worry, your English is very good.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..