Project

General

Profile

First base with USB, OMAP-L138F

Added by Helmut Forren almost 11 years ago

I have inherited development responsibility for a custom base board using an OMAP-L138F SoM. I need to get USB working in one manner or another.

The cable designed by the board originator has a USB-A type plug on it, implying that the originator may have intended the board to act as a USB device that I might plug directly into a Windows PC and use somehow -- I would hope, as a mass storage device giving access to the SoM file system.

However, when I plug that cable into my PC, nothing happens.

As implied, I would like to be able to navigate a Windows Explorer window to the device and browse the target file system. This would allow me to upload and download files more easily. This base board does not have a network connection, and to date it has been a royal pain to have to move the SoM back and forth between the custom base board and the Critical Link base board that does have a network connection. But really, the easiest and calendar-fastest solution would be best, including replacing the cable plug with a socket, then plugging in a USB flash drive. Anything to aid in bi-directional transfer of files between this target and my Windows 7 PC.

Meanwhile, I notice that this Critical Link base board as a USB-A socket, which implies that it wants to be a USB host. This is the opposite of the custom base board created by the originator, my predecessor. This inconsistency concerns me. When I plug a flash drive into it, I get a message "usb 1-1: new full speed USB device using ohci and address 2" on the console. Promising. Of course, I don't know how to access it [yet]. And I don't have a circuit diagram for the Critical Link base board, such that I might compare it to my custom base board to check on whether or not the cable can be converted appropriately. (FWIW, "lsusb" not found. No /dev/sd* files of any name after plugging in.)

Regarding versions, right before my target asks for login, it sends "Angstrom 2010.7-test-20101202 mityomapl138 ttyS1" to the console. The kernel has been modified slightly in the past, but I believe this info still suggests the original basis. In addition, the SDK being used is MDK_2011-12-5.

Any and all advice would be greatly appreciated, especially advice leading directly to getting this working


Replies (12)

RE: First base with USB, OMAP-L138F - Added by Jonathan Cormier almost 11 years ago

It maybe of use to you to have the usb port act as a network device so you can send files over the network. See http://support.criticallink.com/redmine/projects/arm9-platforms/wiki/Enabling_USB_RNDIS_Support.

RE: First base with USB, OMAP-L138F - Added by Jonathan Cormier almost 11 years ago

Once you have the network connection up you can easily move files using ssh and winscp.

RE: First base with USB, OMAP-L138F - Added by Dmitry Gorulko almost 11 years ago

Hello!
If you have got console why don't you just copy files from your PC to board?
And another option - if USB host is available on the board, just connect a USB stick and copy files from it.
Make sure that something like
/dev/mmcblk0p1 /media/card auto defaults,sync,noauto 0 0
exists in the /etc/fstab

RE: First base with USB, OMAP-L138F - Added by Helmut Forren almost 11 years ago

Jonathan, I'll try those things. FYI one test case with a USB flash drive works for the critical link baseboard, but not our custom baseboard. I need to compare schematics. There may be something different, such as failure to provide 5V. If I can get it working with a USB flash drive first, I may then go to the network option...

Dmitry, thanks but it's not so simple. You can't copy files from PC to board merely because you have a console connection. At a minimum, you must have a serial transfer protocol installed. I've done this before. It ends up being way too slow and cumbersome. For example, using ZModem over 115,200 baud gets you way below 11KB/s. But USB 2.0 should get me 38MB/s, which is over 3000 times faster. Gigabyte network might provide 30MB/s, I find after a quick google search, and that's still nearly 3000 times faster than ZModem. So, this factor of 3000 is the difference between usable and not usable. If I am totally mistaken and missing something here, please do correct me. I would like to know, honestly! You did also mention the USB flash drive, which was indeed one of my considerations.

-Helmut

RE: First base with USB, OMAP-L138F - Added by Michael Williamson almost 11 years ago

Schematics for the industrial I/O base board are on this wiki page. Use the most recent one.

There are 2 USB ports available. 1 only supports HOST mode, 1 supports OTG mode (which can be used as HOST or PERIPHERAL) at higher speeds.

The USB OTG port requires proper configuration in the kernel depending on what you are trying to do (act as HOST, PERIPHERAL or OTG port) and will require appropriate drivers to be compiled in (mass storage, RNDIS, etc.).

Which port are you trying to use on your custom design?

-Mike

RE: First base with USB, OMAP-L138F - Added by Helmut Forren almost 11 years ago

Michael,

Great. First, the P/N on my Critical Link baseboard actually matches the next to last, "80-000268RI-2 B". But if I need to make a revision to the board, I'll consult the last entry as you advised.

(((Please humor me while I work through the logic below, in a stream-of-consciousness kind of way.)))

I now find on this schematic that there are TWO usb connectors, one intended for USB Host (that I found, a large USB-A receptacle), and another intended for USB OTG (that I did not notice, a smaller micro receptacle). Furthermore, the datasheet suggests that micro connector go to a PC. Meanwhile, our own baseboard schematic uses USB0, not USB1, and matches the Critical Link baseboard schematic with the exception of not providing a 5V supply. Well, when USB OTG acting as a device to the PC, I suspect that this 5V isn't needed anyway. I just need to continuity test or else find doc for the connector and umbilical cable coming out of the finished unit, to make sure it's wired up OK.

And also check the type of plug needed. Regular USB is 4-pin, but OTG is 5-pin. The umbilical (my word for it) cable has a 4-pin USB-A plug. I forget if in the device role it needs the 5th pin... But I'll find out... Wikipedia says it's all decided by the cable, which has an "A" end and a "B" end. I need the "B" end plugged into our device, so that it will default to being the "B-device", which will be a power consumer (not providing power, as it has none to provide) and act as a peripheral (in my terms, the usb device to the pc's usb host). HOWEVER, ignoring USB standards, the cable is a custom cable that's pluggable, but effectively built into my device. So I need to figure out if it is built in in a manner that makes the embedded OS think it got stuck with the "B" end of the cable!

Going for broke, I tried simply plugging the umbilical's USB-A plug into my PC. But there was no sound and nothing changed on the device manager, including USB section. No bubbles about installing hardware, succeeding or failing. I don't even know yet if the cable is wired reasonably well inside our enclosure. ASSUMING it's wired correctly, is it possible that omission of a USB OTG driver from the kernel would lead to my PC not reacting at all?

From http://www.maximintegrated.com/app-notes/index.mvp/id/1822 about "Host Negotiation Protocol", it seems the A-Device to-be-host must receive the "A" end of the cable, which has the ID pin grounded. Well, in order for my PC to realize it's supposed to be the host in this case, it needs to see that fifth pin grounded. But it only has a 4-pin receptacle. So this can't work. There must be some other way...

So maybe the question boils down to this. Can you plug a USB OTG device into a PC, using what kind of cable, and it all work itself out with the PC as host and the device as peripheral? If so, then I need to rewire or rekernel things to get to this place. If not, then I need to go about things in a different way.

(((NOW, after that thinking process, I ask for more help, please...)))

RE: First base with USB, OMAP-L138F - Added by Jonathan Cormier almost 11 years ago

Mike, Correct me if I'm wrong.

"So maybe the question boils down to this. Can you plug a USB OTG device into a PC, using what kind of cable, and it all work itself out with the PC as host and the device as peripheral? If so, then I need to rewire or rekernel things to get to this place. If not, then I need to go about things in a different way."

For USB 0 the expected connector is the mini connector you see on our board and you would use a normal USB A to USB mini cable to connect to your pc. If i understand you correctly you have attached a USB A connector to USB 0 but haven't hooked up the USB0_VBUS line? A schematic might be helpful.

Reference this page to get network working in the kernel: http://support.criticallink.com/redmine/projects/arm9-platforms/wiki/Enabling_USB_RNDIS_Support

Use our dev kit as reference to get either of these ports working, but as you have it now neither mode will work.

RE: First base with USB, OMAP-L138F - Added by Helmut Forren almost 11 years ago

Jonathan,

Yes, we have a USB A connector coming from USB 0. So this should be akin to connecting a USB A to USB mini cable from the PC to the system. So I should be able to get this work. But no, there is not 5V being provided. You mention "as you have it now neither mode will work." That's not because of the lack of 5V provision, is it? Attached is the circuit diagram (the named USB signals indeed go to the expected places on the SoM connector). As you can see, it's essentially the same as the Critical Link baseboard, with the exception of the 5V.

I saw your note about kernel.

In general, as you might expect, I'm looking for the shortest path from where I am to getting this working!

RE: First base with USB, OMAP-L138F - Added by Jonathan Cormier almost 11 years ago

The only things I see different in your circuit besides the removed 5V vbus switch(U101) are:

  • Missing USB0_ID pulldown (R110)
  • Missing capacitor (C119)

I'm not sure if either of these are required if using the port in peripheral mode only.

I would make the kernel modifications i mentioned. Get it to work on our dev kit and then try it out on your board.

Good luck

RE: First base with USB, OMAP-L138F - Added by Helmut Forren almost 11 years ago

Thanks. I'm tasking my kernel guy on this. The link for RNDIS advice will be helpful.

HOWEVER, I would prefer it look like a mass storage device, so the host PC can directly access the embedded system's file system.

But when I search the wiki, no results come for "mass storage", or even "mass" or "storage" (or "MSC" or "UMS" per wikipedia for usb mass storage device class).

Is there a SHORT PATH for us to get this working?

Thanks again,
Helmut

RE: First base with USB, OMAP-L138F - Added by Michael Williamson almost 11 years ago

Hello Helmut,

This is really an embedded linux question in general and not just a MityDSP-L138 specific question. But to get the OTG port to look like a mass storage device, you will need to enable the MASS STORAGE device gadget in the menuconfig for the kernel. (google "linux mass storagte gadget" should help).

menuconfig -> Device Drivers -> USB Support -> USB Mass Storage Support
menuconfig -> Device Drivers -> USB Support -> USB Gadget Support -> USB Gadget Drivers
menuconfig -> Device Drivers -> USB Support -> USB Gadget Support -> Mass Storage Gadget

You will need to have software configure how the gadget should present the files to the PC using sysfs (check here).

We haven't done this here before (as you can see on the menuconfig, there are 20-30 different gadgets for USB, we don't test all of the possible linux options) as all of our customers use either RNDIS or develop a custom gadget for their USB I/O.

If you need full OS support for options not part of the devkit, we can help/testing for a small support contract, or you might consider Timesys.

-Mike

RE: First base with USB, OMAP-L138F - Added by Michael Williamson almost 11 years ago

And... the capacitance requirements for any USB interface are very important. See the USB specification (usb.org) on the capacitance and in-rush current requirements. If you don't get these right, you may have trouble getting the HOST and the CLIENT to negotiate properly during the bus enumeration cycle. I would fixup the USB_ID0 and cap change.

Hope this helps.

-Mike

    (1-12/12)
    Go to top
    Add picture from clipboard (Maximum size: 1 GB)