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

Are you using USB as OTG? Host or peripheral mode for your test?

If you do a dmesg (before and after plugging in a USB device), do you see anything related to USB?

The driver for the ARM in OTG mode wants to see the VBUS in toggle during initialization (it controls the +5V local supply based on what mode it needs to present as), if you don't have the +5V control and power hooked up that may be part of the problem. Also, how do you have your USB configured in the kernel board file?

Hi Mike,

Are you using USB as OTG? Host or peripheral mode for your test?

In our tests, the device acts as the peripheral and the computer as the host.

If you do a dmesg (before and after plugging in a USB device), do you see anything related to USB?

I did a dmesg before and after plugging the USB, but the output is the same. I've attached the output.

The driver for the ARM in OTG mode wants to see the VBUS in toggle during initialization (it controls the +5V local supply based on what mode it needs to present as), if you don't have the +5V control and power hooked up that may be part of the problem.

That reminds me of a warning message the kernel prints during every boot. The same message was printed when I issued the dmesg command:

------------[ cut here ]------------
WARNING: at arch/arm/mach-davinci/da850.c:1109 da850_regulator_init+0x30/0x54()
Unable to obtain voltage regulator for CVDD; voltage scaling unsupported

Could this be what causes the problem?

Also, how do you have your USB configured in the kernel board file?

I don't, actually. I just enable "Inventra HDRC USB Peripheral" and "Gadget Filesystem" options as built-in via menuconfig and build the kernel. This was how I did it with the Critical Link's board, which worked, and I do the same thing while configuring USB for the custom one. Is something wrong about it?

Thanks again,
Okan

So if you are trying to run in peripheral mode, I am not entirely sure I understand the last lines of your log file:

...
nop musb-hdrc: failed to start (null): -120
gadgetfs: bound to musb-hdrc driver
musb-hdrc musb-hdrc: MUSB HDRC host driver
musb-hdrc musb-hdrc: new USB bus registered, assigned bus number 2
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 1 port detected
musb-hdrc musb-hdrc: remove, state 4
usb usb2: USB disconnect, device number 1
musb-hdrc musb-hdrc: USB bus 2 deregistered

Do you see these lines even if you don't connect the PC? (I was looking to see if the kernel is detecting when you plug in the PC and complaining about something, or if it doesn't see any activity at all).

Do you see those messages when you run on the Critical Link DevKit board?

Can you share (offline) your baseboard schematic?

Do you see these lines even if you don't connect the PC?

Yes, I see those lines even when not connected to the host.

I did a dmesg in the Critical Link board, but those lines don't appear there (when not connected).

Can you share (offline) your baseboard schematic?

I have no idea if I have that kind of clearance; I must consult to my superiors first.

Could you attach your .config?

By default, CONFIG_USB_MUSB_OTG is selected which puts the kernel in OTG mode. In this mode, if USB*_ID is pulled low then the device enters host mode and if its left floating then its in Peripheral mode. An earlier design of our devkits had a pull down resistor installed which put the USB into HOST mode. This resistor R110 was not populated in later designs to fix this. See below.

If you do have this pull down in your design and you don't need OTG mode only Peripheral, you can change from CONFIG_USB_MUSB_OTG=y to CONFIG_USB_MUSB_PERIPHERAL=y which should cause it to ignore the ID pin and always use Peripheral mode.

See highlighted "Driver Mode"

If this doesn't fix things, the next troubleshooting step would be to measure the voltages on the USB pins when its disconnected and then when its connected and post them.

Michael Williamson wrote:

Do you see these lines even if you don't connect the PC? (I was looking to see if the kernel is detecting when you plug in the PC and complaining about something, or if it doesn't see any activity at all).

Do you see those messages when you run on the Critical Link DevKit board?

The reason why those messages appeared when I did a dmesg was because I issued the command after I had executed the Linux application, which attempts to connect to a host through USB-GadgetFS. The application prints the "hub 2-0:1.0: USB hub found" code and others as soon as you execute it, without actually connecting the USB. This is the same in the Critical Link's board as well, so I don't think that's a problem. The messages don't appear with a dmesg if you don't execute the GadgetFS code.

Jonathan Cormier wrote:

Could you attach your .config?

I've attached it.

If you do have this pull down in your design and you don't need OTG mode only Peripheral, you can change from CONFIG_USB_MUSB_OTG=y to CONFIG_USB_MUSB_PERIPHERAL=y which should cause it to ignore the ID pin and always use Peripheral mode.

I consulted to my colleagues, who said the ID pin is already floating. Still, I tried forcing the kernel to peripheral mode, but that option seems to be missing in both menuconfig and the .config file.

Another point is, the baremetal code that works gets the DSP core to use the USB, whereas I'm trying to make the ARM use the USB, and it fails (though it does work on MityDsp). Could it be because the ARM's having trouble accessing the USB?

Thanks again,
Okan

Okan Çalış wrote:

Michael Williamson wrote:

Do you see these lines even if you don't connect the PC? (I was looking to see if the kernel is detecting when you plug in the PC and complaining about something, or if it doesn't see any activity at all).

Do you see those messages when you run on the Critical Link DevKit board?

The reason why those messages appeared when I did a dmesg was because I issued the command after I had executed the Linux application, which attempts to connect to a host through USB-GadgetFS. The application prints the "hub 2-0:1.0: USB hub found" code and others as soon as you execute it, without actually connecting the USB. This is the same in the Critical Link's board as well, so I don't think that's a problem. The messages don't appear with a dmesg if you don't execute the GadgetFS code.

Jonathan Cormier wrote:

Could you attach your .config?

I've attached it.

If you do have this pull down in your design and you don't need OTG mode only Peripheral, you can change from CONFIG_USB_MUSB_OTG=y to CONFIG_USB_MUSB_PERIPHERAL=y which should cause it to ignore the ID pin and always use Peripheral mode.

I consulted to my colleagues, who said the ID pin is already floating. Still, I tried forcing the kernel to peripheral mode, but that option seems to be missing in both menuconfig and the .config file.

Woops sorry I was looking at the 2.6 kernel sources. In the 3.2 branch Peripheral mode can be configured in the baseboard.

 $ ag mityomapl138_usb_init
arch/arm/mach-davinci/include/mach/da8xx.h
102:int __init mityomapl138_usb_init(int);

arch/arm/mach-davinci/baseboard-CIS10XX.c
133:    mityomapl138_usb_init(MUSB_PERIPHERAL);

arch/arm/mach-davinci/baseboard-continuum.c
141:    mityomapl138_usb_init(MUSB_PERIPHERAL);

arch/arm/mach-davinci/baseboard-dbric3.c
178:    mityomapl138_usb_init(MUSB_OTG);

arch/arm/mach-davinci/baseboard-industrialio.c
460:    mityomapl138_usb_init(MUSB_OTG);

arch/arm/mach-davinci/baseboard-clomapl138uc.c
142:    mityomapl138_usb_init(MUSB_OTG);

arch/arm/mach-davinci/baseboard-irdc.c
229:    mityomapl138_usb_init(MUSB_OTG);

arch/arm/mach-davinci/baseboard-testfix.c
232:    mityomapl138_usb_init(MUSB_HOST);

arch/arm/mach-davinci/baseboard-usm.c
351:    mityomapl138_usb_init(MUSB_HOST);

arch/arm/mach-davinci/baseboard-wiu.c
300:    mityomapl138_usb_init(MUSB_HOST);

arch/arm/mach-davinci/baseboard-r2.c
448:    mityomapl138_usb_init(MUSB_OTG);

arch/arm/mach-davinci/baseboard-hfm.c
161:    mityomapl138_usb_init(MUSB_OTG);

arch/arm/mach-davinci/board-mityomapl138.c
582:__init int mityomapl138_usb_init(int usb2mode)

Another point is, the baremetal code that works gets the DSP core to use the USB, whereas I'm trying to make the ARM use the USB, and it fails (though it does work on MityDsp). Could it be because the ARM's having trouble accessing the USB?

It seems unlikely that it would be a problem if it works fine on the Devkit.

Jonathan Cormier wrote:

In the 3.2 branch Peripheral mode can be configured in the baseboard.

That actually worked. Thanks!

I edited "baseboard-industrialio.c" and set the USB mode as peripheral. Somehow, our custom board needed to be forced to run in peripheral mode, while MityDsp didn't.

Glad it worked. I suspect your ID pin is being pulled low somehow. But as long as you don't need to support HOST mode, there should be no problem with forcing Peripheral mode.