Other Parts Discussed in Thread: OMAP-L138
During our process it is standard practice to run 100% of the units over the full range of environmental conditions the product is specified to support. This includes temperature (0degC to +40degC), voltage (+5VDC to +24VDC), and vibration (10Grms).
During testing we have seen a number of units experience longs delays in responding to requests made via the Ethernet port. During testing of the Ethernet port the USB port is “disconnected” using a custom test card. This card isolates the USB VBUS and data lines, emulating the removal of the cable from the unit under test. After much debugging we have discovered that with the USB port disconnected, some units exhibit a flurry of USB interrupts related to the USB0 peripheral sensing the SUSPEND state. I looked at the state of the USB DP and DM signals and indeed this is the state they are in. With the bus in this state we would expect to get an interrupt at regular intervals of the SUSPEND timeout which is at least 3.0ms. The interrupts we observed are occurring on the order of 20 microseconds. When this situation arises the DSP is essentially locked up trying to service this interrupt storm and cannot perform other tasks. The severity and frequency of occurrence of this problem varies from unit to unit and has also shown a temperature dependency.
Has anything like this been reported by other uses of the OMAP-L138?
I should note that our design does not connect the VBUS sense input of the USB0 core directly to the USB VBUS signal. Because this is a universal design intended for applications which might not even use USB for connectivity we chose to create an LVTTL signal and route it to a GPIO pin on the DSP. We disable the VBUS comparators and set the core to operate without requiring it to detect a proper voltage level on VBUS. The configuration we use is highlighted in RED below.
We have instituted a work-around wherein we keep the USB0 peripheral interrupts disabled until we detect the presence the VBUS detect signal we created on the GPIO. Out testing thus far indicates that this solves the problem. Based upon the description for a USBOTGMODE bit-field setting of 0 my suspicion is that we shot ourselves in the foot by not connecting USB VBUS line directly to the VBUS sensing input of the DSP. A confirmation of this would be helpful.
Chip Configuration 2 Register (CFGCHIP2)
Bit Field Value Description
16 USB0VBUSSENSE Status of USB2.0 PHY VBUS sense.
0 PHY is not sensing voltage presence on the VBUS pin.
1 PHY is sensing voltage presence on the VBUS pin.
14-13 USB0OTGMODE USB2.0 OTG subsystem mode.
0 No override. PHY drive signals to controller based on its comparators for VBUS and ID pins.
1h Override phy values to force USB host operation.
2h Override phy values to force USB device operation.
3h Override phy values to force USB host operation with VBUS low.
4 USB0VBDTCTEN USB2.0 VBUS line comparators enable.
0 All VBUS line comparators are disabled.
1 All VBUS line comparators are enabled.
