LPC4333 high-speed USB

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

LPC4333 high-speed USB

1,298 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by svenb on Thu Oct 23 07:38:21 MST 2014
Hi!

I am using the LPC43xx virtual serial device example (with USB0) from lpcopen. It works fine, but in full-speed mode. As a test, I want to run it in high-speed mode, but can't figure out what to change to make this work.

I made sure the "force fullspeed" bit is not set in the LPC_USB0->PORTSC1_D register. Unless that is the case, I assumed that the chip would always advertise its high-speed capabilities to the host controller by sending a chirp during the first (?) reset -- which I do not see happen on my oscilloscope (the scope is 200 MHz bandwidth though, so not sure if I would see it -- the 480 MHz USB clock is visible though if sent to CLKOUT, so I would expect to see the chirp as well).

In dmesg I see this when I connect the device:
[ 4094.298593] usb 2-1.1: new full-speed USB device number 38 using ehci-pci
[ 4094.386331] cdc_acm 2-1.1:1.0: ttyACM0: USB ACM device


When I also send a "DeviceQualifier" type descriptor, I get this:
[ 3024.839243] usb 2-1.1: new full-speed USB device number 29 using ehci-pci
[ 3024.923152] usb 2-1.1: not running at top speed; connect to a high speed hub
[ 3024.925337] cdc_acm 2-1.1:1.0: ttyACM0: USB ACM device

but the hub is definitely high-speed capable and other devices work in high-speed on the same hub and port.

This is the output of lsusb -v for the device:
Bus 002 Device 038: ID 1fc9:2047 NXP Semiconductors 
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            2 Communications
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  idVendor           0x1fc9 NXP Semiconductors
  idProduct          0x2047 
  bcdDevice            0.01
  iManufacturer           1 NXP
  iProduct                2 xx xx xx xxxxxxxx
  iSerial                 0 
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           62
    bNumInterfaces          2
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0x80
      (Bus Powered)
    MaxPower              500mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         2 Communications
      bInterfaceSubClass      2 Abstract (modem)
      bInterfaceProtocol      1 AT-commands (v.25ter)
      iInterface              0 
      CDC Header:
        bcdCDC               1.10
      CDC ACM:
        bmCapabilities       0x06
          sends break
          line coding and serial state
      CDC Union:
        bMasterInterface        0
        bSlaveInterface         1 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0008  1x 8 bytes
        bInterval             255
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass        10 CDC Data
      bInterfaceSubClass      0 Unused
      bInterfaceProtocol      0 
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x03  EP 3 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0010  1x 16 bytes
        bInterval               1
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x82  EP 2 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0010  1x 16 bytes
        bInterval               1
Device Status:     0x0000
  (Bus Powered)


Any ideas what the reason could be that it doesn't use high-speed mode?
I tested setting the wMaxPacketSize to 512 for all endpoints; the example stopped working (not sure why), but the USB connection was still made in full-speed mode.

Especially: Is it even possible that something which is wrong in the descriptors causes the chirp not to happen?

Could this be related to clock setup somehow? For some reason, the example code did not really configure the USB PLL, it just turned it on; I had to configure it for 480 MHz manually.

I did a lot of measurements and fiddling on the chip and it's possible I destroyed something. Could this be a hardware defect of the High-Speed part of the PHY?

Attached is an image of the reset cycle when the device is plugged in. As you can see, there's no chirp.

The electrical layout of the board is custom, so if you think this could be an electrical problem, I'll be happy to provide the relevant information.

Thanks and best regards,
Sven
Labels (1)
0 Kudos
Reply
9 Replies

1,116 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by svenb on Tue Oct 28 17:30:56 MST 2014
Found it. I did not connect the 12k current reference resistor.

I understood it as "here is a 12k resistor to ground on the chip for when you want to measure current consumption of an attached device when the microcontroller is operating in host mode". Maybe I'm stupid, but I think a wording which is a bit more explicit about that an external resistor is required on that pin would be nice.
0 Kudos
Reply

1,116 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by svenb on Tue Oct 28 12:38:34 MST 2014
New board, exactly the same behaviour.

Any ideas? I'm really clueless :(

Any information which could help you find the issue?
0 Kudos
Reply

1,116 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by svenb on Tue Oct 28 09:34:00 MST 2014
I replaced my 4 MHz crystal with a 12 MHz one, and the bootloader runs in full-speed as well. The chirp is not visible on the bus, like for my code. I will build a second board and see if it works there.
0 Kudos
Reply

1,116 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by svenb on Sat Oct 25 04:54:16 MST 2014
Related question: My device is bus-powered, and I simply connected the 5V VBUS directly to the VBUS pin of the chip; VDD is provided by a linear regulator which is powered by VBUS and has some capacitance (2.2uF) at its output. So it might be possible (I don't know exactly) that 5V is present on the VBUS pin of the controller for a few microseconds before VCC has reached 3.3V. Could that cause trouble or even damage?

Edit: Ok, the answer to this question seems to be "no": http://www.lpcware.com/content/forum/usb0vbus-connection-self-powered-usb-device
0 Kudos
Reply

1,116 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by svenb on Fri Oct 24 05:32:59 MST 2014
Ok, so I should see it. The question is, why isn't it there? :-)
0 Kudos
Reply

1,116 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by starblue on Fri Oct 24 05:15:26 MST 2014
Yes, I also think so, here is a concise explanation:

http://www.usbmadesimple.co.uk/ums_6.htm#negotiating_high_speed

I just tried it with my Windows PC and a USB stick. With trigger on positive pulse >500µs it is easy to see chirp K on my scope (repeated ~50µs on ~50µ off pattern).

Jürgen
0 Kudos
Reply

1,116 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by svenb on Fri Oct 24 04:42:30 MST 2014
I read a bit in the USB 2.0 specification, section 7.1.7.5, "High-speed Detection Handshake". It says that the pattern must be between 40 and 60 microseconds for each individual chirp. That sounds like it should be easy to detect with my scope, no?
0 Kudos
Reply

1,116 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by svenb on Thu Oct 23 16:21:58 MST 2014
Ok, thanks. I googled some images of what the chirp should look like, and it seemed reasonably low in frequency that I would have expected to see at least something, some noise or so. But it's good to know that it probably won't work.

The hub is fixed in my notebook, what could I do if I could remove the hub?

Thanks and best regards,
Sven
0 Kudos
Reply

1,116 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by rocketdawg on Thu Oct 23 14:34:25 MST 2014
You will never see the chirps with a 200 Mhz scope.  To see anything you would need about 1 GHz with a expensive differential probe and to see valid waveforms you need about 2.5 GHz scope and a 4 G probe.

Can you remove the hub or is it internal to the PC?
0 Kudos
Reply