Mity CPU Platforms » MityDSP-L138 (ARM9 Based Platforms)

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.

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

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

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

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

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...)))

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.

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!

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

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

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

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