I have attached the schematic of the USB host interface we are using. It was found that the USB host power pin 129 (Colibri iMX6) is not changing states when any USB device/memory is plugged into the socket. I tried tieing the enable pin to High (3.3V) on the MIC2076 chip’s pin 1, disconnecting it from USBH.PWR.EN, and it works for the first time. Unplugging and plugging the USB stick is not recognized anymore, only reboot works.
Question is, how to make USBH.PWR.EN pin working.
What version of the OS image are you currently using?
We added some fixes for USB device detection in release 1.1B2.
I am using 1.1B2. I tried a hardware inverter after USB_PWR_EN pin and before ENA of MIC2076 chip.
I measured the voltage on ENA of MIC2076 (after the inverter) and found that the pin goes HIGH the first time I connect the USB stick and it recognizes the USB drive. Unplugging the USB stick does not make it LOW and it stays HIGH. So, subsequent plugging doesn’t work. But with this pin kept high, the keyboard works fine. subsequent plugging of the keyboard works.
Does it happen on your side on 1.1B2?
Dear marifhossain,
I will try to clarify the behavior of the USB_PWR_EN# signal in order to make sure you are using correctly this signal.
First of all, the USB_PWR_EN# is an “Active Low” signal. It means that the USB Power is enabled when this signal is low, 0V.
I have checked your device (MIC2076-2YM) and this is actually an “Active Low” device. This means that you should connect the pin 129 of our Colibri module to this device enable pin directly (or with a 22R resistor), without the need of an inverting circuit.
When the module boots, it pulls the USB_PWR_EN# to 0V to enable the USB Host Power distributor chip.
This is done automatically in the boot sequence, if the software on the module is correct.
The USB_PWR_EN# signal does not get enabled when a device is connected to the USB port because, if this signals is not enabled, the USB port does not have power and the device would not work at all.
So, I would recommend the following steps to debug the situation:
I really hope this helps. Please don’t hesitate to write again if you have further questions.
Sorry, the schematic was incorrect and we had MIC2076-1YM, so we needed an inverter.
Now, with V1.1B2 using hardware inverter and pull-ups and found that USB keyboard mouse working fine. No issues, but USB memory stick works only once and needs re-boot to detect and work again. Measured the USB_OC and that’s HIGH with the memory stick in.
I tried connecting the MIC2076-1YM’s ENA directly to HIGH (removing the ic pin from the pad obviously) and it showed the same characteristics as above, memory stick needs re-boot of the system.
It looks strange to me that it works only once.
So you basically connect the first time, and works.
Then you unplug and plug again and it does not work.
Does the LED which is on the memory stick blink when you insert the second time? If yes, this would mean that the Memory stick gets the Power. you can also measure that, when you connect the second time the Memory stick, there is power on the pin number one of the USB connector.
Once we exclude the power, we should probably focus our attention on the signal routing. Normally Mice and Keyboard are working with USB Full speed wich is not that problematic (even if the layout is not optimum it normally works).
Memory Stick are normally using a High speed interface which is a bit more sensitive to layout issues.
Could you please share with me a picture in which you highlight the USB traces you have on your carrier board?
In addition: I guess that R401-402 etc are assembly option right?
We found that a ASUS 32 MB (megabyte) USB stick is working fine. Plugging unplugging has no issues. Only issue we are facing with 8GB and 32GB sticks.
Our hardware engineer said he had experienced issues like this where the USB clock deviates from 12Mhz.
We found that Colibri Evaluation Board works fine as it has its own dedicated oscillator (24Mhz). We suspect that Colibri modules USB driver have some issues with the clock or the driver itself has some limitation. Could you check at your end.
This is the ASUS purple 32 MB USB drive that is working amazingly. I tried to format a 8GB drive as 32 MB but it didn’t work.
http://ixbtlabs.com/articles2/flashdrives/flashdrives-asus-eline-kingmax-luwen-xmicro.html
My colleague told me that this drive is formatted as floppy drive and shows as floppy drive in his laptop. Point to note.
Also, This shows two drives interestingly. USB HD and USB HD2 when plugged in.
Dear @marifhossain, could you please be so kind to send a picture showing the USB layout? Maybe a screenshot of your CAE tool, in which the USB lines are highlighted.
I would like to check the way you have actually routed this port, to see if the issue you are experiencing are not related to that.
I think that it makes sense also to make sure you have followed the rules explained in the following document:
Please focus your attention to the paragraphs 6.6, 6.7, 6.8, 7.4.
I hope this helps.
We are using USBA port for the USB drive. The layer around and layer underneath is a ground layer. Please see the attachment.link text
I am not a hardware guy but still it doesn’t make sense to me that it’s a hardware problem. Because if it would be, then it should not work with the 32MB drive (as floppy) every time and flawlessly. I strongly believe this is a driver issue or clock mismatch issue. The problem only happening in the absence of the USB hub chip with its own clock (24Mhz).
Can you do some experiment at your end without the USB Hub chip used in the evaluation board?
We have found something! If we add an external USB hub, it works fine. We are using a 3 ft cable between the hub and the toradex PCB.
So, that way we can eliminate the PCB tracking issue you are pointing out from the begining. Please now focus on the software and driver and check if there is any parameter related to the driving signal current inside the Colibri Module.
It’s definitely a hub related issue. Please, we need to have a solution quickly on this. So please start investigating this on the software side and also investigate the clock mismatch we pointed out.
In version 1.1B4 (available for download today) we fixed some issues about device detection for ports that are directly connected to the module, not using hub.
Can you please download and test this release?
Thank you
