DM8148 Multiple re-enumeration of HID Mouse

Padmanabhan,

Are you using EZSDK 5.05.02.00 / PSP 04.04.00.01 or else?

How do you handle the USB_ID pin? Are you aware of the below limitation and workaround:

http://processors.wiki.ti.com/index.php/DM81xx_AM38XX_USB_User_Guide#USB_ID_configuration_for_DM814x

Regards,
Pavel

Padmanabhan,

When I use the EZSDK 5.05.02.00 / PSP 04.04.00.01 on the DM8148 TI EVM, the USB mouse is working fine.

When the mouse is detected and enumerated, it is stable in its functioning. I mean it is not disconnected till I manually remove it from the USB slot.

I have the below console output when I plug the USB mouse:

usb 1-1: new low speed USB device using musb-hdrc and address 2
usb 1-1: New USB device found, idVendor=093a, idProduct=2516
usb 1-1: New USB device strings: Mfr=0, Product=2, SerialNumber=0
usb 1-1: Product: USB OPTICAL MOUSE
input: USB OPTICAL MOUSE as /devices/platform/omap/ti81xx-usbss/musb-hdrc.0/usb1/1-1/1-1:1.0/input/input1
generic-usb 0003:093A:2516.0001: input: USB HID v1.11 Mouse [USB OPTICAL MOUSE] on usb-musb-hdrc.0-1/input0

Then I have the below console output, only when I manually remove the USB mouse:

usb 1-1: USB disconnect, address 2

The only thing I have change from the default TI814x kernel config (ti8148_evm_defconfig) is switching from USB_ID pin software setting to usb connector, see the below wiki page for more info:

http://processors.wiki.ti.com/index.php/Usbgeneralpage#USB-ID_pin_configuration_selection_for_TI81XX

BR
Pavel

Hi Pavel,

Yes. We are indeed using EZSDK 5.05.02.00 / PSP 04.04.00.01 .

THE USB0 ID Pin is short to GND since USB0 is intended to be host all the time.

Also, the USB0MODE register is 0. From the TRM, if USB0MODE=0, the state of the USB_ID pin controls the role the controller assumes i.e host.

Anything else that can help me check whether all settings are ok? Any other register that needs tweaking?

Regards,

Padmanabhan

Pavel,

I just came across Evtest.zip application which seem to capture all HID events.

I have just shared the same with the software guys and asked them to check it out.

This is under USB HID Class sub-section from the Linux USB configuration webpage -http://processors.wiki.ti.com/index.php/Usbgeneralpage#USB_Controller_and_USB_HID

Have you used this before?

Regards,

Padmanabhan

Padmanabhan,

If one SW works fine on one board, and the same SW does not work on other board, then I think this is HW design issue. I don't think changing the SW (modifying USB registers) will help you here.

Can you try with other USB mouses, do you have the same?

It seems to me that the connection of the USB mouse and the USB port (of the DM814x device) is not very stable, that is why you have this connect/disconnect/connect behaviour.

Please double check the HW design of your custom board, using the below resources:

DM814x datasheet, 8.22 USB

DM814x TRM, section 25.5.4 VBUS Voltage Sourcing Control

http://processors.wiki.ti.com/index.php/DM814x_Hardware_Design_Guide

http://processors.wiki.ti.com/index.php/AM387x_/_C6A814x_Schematic_Review_Checklist

http://www.ti.com/lit/an/spraar7a/spraar7a.pdf

The Mistral DM8148 EVM reference schematics

http://www.mistralsolutions.com/pes-support/support-downloads/tmdxevm8148.html#

The Mistral EVM USB diagnostic software tests (BB_017_USB0_HOST_Test.out)

Regards,
Pavel

Padmanabhan KS said:

I just came across Evtest.zip application which seem to capture all HID events.

Padmanabhan KS said:

Have you used this before?

No I haven't. Below is what I have found regarding Evtest:

http://processors.wiki.ti.com/index.php/Evtest

http://e2e.ti.com/support/arm/sitara_arm/f/791/p/264875/926423.aspx#926423

http://e2e.ti.com/support/embedded/linux/f/354/p/120577/507040.aspx#507040

http://e2e.ti.com/support/embedded/linux/f/354/p/136822/507039.aspx#507039

http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/100/p/8332/33729.aspx#33729

Regards,
Pavel

Pavel,

We did some more testing/isolating. The issue is reproduced more frequently  using particular brand of mouse (Lenovo) compared to others.

Also, we reproduced the same using 8148 Mistral eval kit using the Lenovo mouse.

So too early to say its hardware problem I think.

On checking the web, seems like few  people have faced this issue even while using different flavors of Linux in their PCs. There is also a discussion about Auto-suspend being disabled although there seem to be no conclusion.

https://bbs.archlinux.org/viewtopic.php?pid=1178070

Padmanabhan,

As you are using PSP04.04.00.01, can you try apply all the USB related patches on top of the PSP 04.04.00.01? You will find these patches in the below ti81xx master branch:

http://arago-project.org/git/projects/?p=linux-omap3.git;a=shortlog;h=refs/heads/ti81xx-master

May be some of these USB patches will fix that, I think it is worth to try that.

Regards,
Pavel

Pavel,

Our software guys just confirmed that they encounter the connect/disconnect even after applying the relevant patches from that list.

Just wondering why this happens even though we do not see any functionality issue. Oh well - may be it happens too quickly for mouse movements/tracking to be affected.

Regards,

Padmanabhan

Padmanabhan,

I have tested with two delux usb mouse devices, I can not reproduce this issue.

Can you check if the failing usb mouse devices are compatible with the 2.6.37 kernel? I suspect these usb mouse devices are designed to work with the 3.x linux kernel and are not backward compatible with 2.6.37 linux kernel. This can be check with the usb mouse specification.

Also, if this is brand new usb mouse, does it have new feature like auto-suspend (when no action) after several minutes?

Regards,
Pavel

Padmanabhan,

I have three more points:

1. I tried with Asus/Logitech usb mouse, no re-enumeration issue is observed, I have the below console output:

root@dm814x-evm:~# usb 1-1: new low speed USB device using musb-hdrc and address 2
usb 1-1: New USB device found, idVendor=046d, idProduct=c019
usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 1-1: Product: USB Optical Mouse
usb 1-1: Manufacturer: Logitech
input: Logitech USB Optical Mouse as /devices/platform/omap/ti81xx-usbss/musb-hdrc.0/usb1/1-1/1-1:1.0/input/input1
generic-usb 0003:046D:C019.0001: input: USB HID v1.11 Mouse [Logitech USB Optical Mouse] on usb-musb-hdrc.0-1/input0

2. If you enable debug level 8 for the USB driver, will you have more informative console output during the re-enumeration?

http://processors.wiki.ti.com/index.php/Usbgeneralpage#procfs

3. The voltages are somehow dropping out of spec for your specific usb mouse devices. You can try also connect your USB mouse device through a self powered USB hub (USB hub has its own power supply).

BR
Pavel

Hi Pavel

Thanks again for the inputs. I have shared the procfs debugging info with our software team and once I hear from them, shall keep you updated.

Meanwhile, we plugged in two relatively 'old' USB mouses to our PCBA and was left on over the weekend. Not a single re-enumeration took place. 

I also checked the specification of the 'new' mouse(which triggered re-enumeration) and found that they support Kernel 2.6 and later. But i can't confirm the 'auto-suspend' feature for these new mouses though. Could not dig up relevant information for that.

Regards,

Padmanabhan

Pavel,

It is easier to reproduce the problem in DM8148 eval kit if the UI is disabled. This was observed by our team.

Disable auto load of the GUI application "matrix-gui-e" and use the console only.  

To disable the GUI application, go to /etc/init.d, modify the script "matrix-gui-e"

Please try it and let us know if you have a similar observation.

Regards,

Padmanabhan

Padmanabhan,

I stopped the matrux-gui-e by the below command:

root@dm814x-evm:~# /etc/init.d/matrix-gui-e stop
Stopping Matrix GUI application.

Then I tried with two usb mouse devices (Delux and Asus/Logitech) but I can not reproduce the re-enumeration issue with these two mouses (which are relatively old).

The only thing I can observe when stopping the matrux-gui-e is that the cursor of the USB mouse disappear and the mouse does not work at all (but no connect/disconnect is observed).

BR
Pavel

Hi

I have seen some mouse will disconnect automatically if there is not interrupt ep request from host or if host is idle and not using the mouse device.

Can you try is the behavior is same in your case. run evtest application and check this issue reproducible.

Regards

Ravi B