1
\$\begingroup\$

I have been designing a usb device using a psoc 4L with integrated USB full speed capability. Yet for nearly all of my designs as soon as I plug the usb into the computer I get the following problem.

worst description of a problem ever

From the research I've been able to dig into, this suggests that there is something wrong on my physical layer (I'm using a generic starter project provided by cypress, and occasionally I have had it correctly connect)

I've measured the D+ and D- lines and here are the pictures from my o-scope Zoomed out Zoomed in oscope

My question is what appears to be the problem here?

My intuition suggests that D+(the blue trace) is taking too long (18 ns which is greater than 12 ns allowed) Therefore it has too much capacitive loading and I need to identify in the layout what could be adding to it. Is this correct intuition, or is something completely different going on?

EDIT *******

I redid the scope with measurements on. here it is. Looks like the voltage is consistently around 4.1V enter image description here

EDIT # 2*******

I got it to work! I was originally powering the psoc 4 off of the miniprog. As soon as I switched to USB powered it worked. I'm talking with some cypress FAE's so as soon as I get an answer as to why that would be the problem, I'll post here

\$\endgroup\$
8
  • \$\begingroup\$ Does it work on *nix? \$\endgroup\$
    – uint128_t
    Commented Apr 26, 2017 at 0:35
  • \$\begingroup\$ Is that really ~4V on the data lines? \$\endgroup\$
    – FRob
    Commented Apr 26, 2017 at 1:33
  • \$\begingroup\$ This is likely to be a problem with your firmware. Try to use one of the examples without any changes. Show what Linux writes to the system log. \$\endgroup\$
    – CL.
    Commented Apr 26, 2017 at 7:09
  • \$\begingroup\$ @uint128_t I haven't tried on *nix. Could I create a virtual machine and pass the usb through that way, or would I need a dedicated box? \$\endgroup\$
    – Legen Diary
    Commented Apr 26, 2017 at 16:03
  • \$\begingroup\$ @FRob that's what it looks like. Could that be a worthwhile point of debugging? \$\endgroup\$
    – Legen Diary
    Commented Apr 26, 2017 at 16:04

3 Answers 3

Reset to default
1
\$\begingroup\$

Your waveforms look OK IMO. You need to check how far you are getting in the enumeration process. You can do that by checking the unknown device in DeviceManager. Look to see if the VIP/PID is being detected in the initial negotiation.
If you have a VIP/PID, then you are getting quite far in the enumeration.
If the VIP/PID is zero then you are failing early in enumeration, or don't have a recognizable VIP/PID.
Your project should have a VIP/PID defined for a HID device which should be automatically resolved by Windows.

While there are commercial and free USB analyzers for Windows, you can also simply use the Microsoft Windows Message Analyzer to capture the USB traffic. For this to work the base Phy protocol (things like you USB levels and clocks) must be running OK. However it looks like you are fine here and should be able to capture the traffic successfully.
There are online videos within the MMA interface that will show you how to operate the MMA or use the ones here ....and the operating manual is here.
It's not a simple tool, but well worth getting to know.

\$\endgroup\$
0
\$\begingroup\$

The message you see essentially means that your device is plain dead, it can't complete basic enumeration process. It could be that it is either completely dead, or just doesn't return correct descriptor information without protocol error.

The fact that the device gets connected and your USB host pulls out frame packets, your device is not completely dead, but the USB engine doesn't function correctly.

The signals are looking quite normal, except that the level, as other noted, is a bit too high. Frequency is right. But again, the signals you see are likely coming from your USB host, which has likely nothing to do with your device. (to get a capture of a very sporadic device response you need to work pretty hard, and get a special test fixture with a reference USB device, then use 3-channels to differentiate the packets by their EOPs).

The most productive way to debug the USB physical layer is to get a USB protocol analyzer, like this one.

\$\endgroup\$
2
  • \$\begingroup\$ While they can ultimately see more, before purchasing hardware monitors, it would be worth seeing if no-cost software USB monitors can see enumeration traffic and descriptors up to a point of failure or unexpected response. Around Windows 7 there was something free available from Microsoft for this which may or may not still exist. On Linux wireshark will typically do it. \$\endgroup\$
    – Chris Stratton
    Commented Apr 27, 2017 at 0:08
  • \$\begingroup\$ @ChrisStratton, yes, there are system tools, Microsoft Message Analyzer for one. technet.microsoft.com/en-us/library/jj649776.aspx However, it is a pain in a butt to configure proper session, "provider fields", filtering, etc etc. I found the tool quite useful if some other MS professional would configure the trace capture for me, but I wasn't able to configure anything by myself, very sad. Even the Android was easier to get proper traces. \$\endgroup\$
    – Ale..chenski
    Commented Apr 27, 2017 at 2:38
0
\$\begingroup\$

You can use USBPcap to capture USB packets and see where things go wrong.

\$\endgroup\$
4
  • \$\begingroup\$ The USBPcap seems like a nice product. Unfortunately, I don't see it capturing the enumeration process, where the problem seems to occur, the log always starts with device already having the address set. Is there any way to capture the enumeration process? \$\endgroup\$
    – Ale..chenski
    Commented Apr 30, 2017 at 0:16
  • \$\begingroup\$ @AliChen some of the setup is captured, you can read the detail here \$\endgroup\$
    – neonzeon
    Commented Apr 30, 2017 at 4:10
  • \$\begingroup\$ Yes, exactly, the document says, "Moreover, you won't see complete USB enumeration. You will only see the USB control transfer send to device after the device has been assigned its address." So the main stage when the OP's device has likely failed (not responding to GET_DESCRIPTOR from default pipe 0) won't show up. The trace probably will be empty. \$\endgroup\$
    – Ale..chenski
    Commented Apr 30, 2017 at 4:46
  • \$\begingroup\$ @AliChen indeed - I've not used the Windows Message Analyzer described by Jack Creasy but at least that's not $800. \$\endgroup\$
    – neonzeon
    Commented May 1, 2017 at 2:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.