• State
  • Locked Locked
  • Replies 9 replies
  • Subscribers 101 subscribers
  • Views 1371 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM3352, USB device not detected, no /dev/ttyACM0

didier cadiou
Intellectual 350 points
Other Parts Discussed in Thread: AM3352, CC2531

Hi.

I'm working on a custom board built around an AM3352 processor. This board is closed to the sitara EVM SK demoboard, but with less features.

One new feature, thus, is an USB module using a TI CC2531 chip, built on the same board as the AM3352, and connected to it using USB1_DP and USB1_DM connections.

Unfortunatly, this module is not detected by the AM3352.

lsusb command returns :

Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub


cat /proc/driver/musb_hdrc.1 command returns :

Status: MHDRC, Mode=Host (Power=e0, DevCtl=91)
OTG state: a_idle; inactive
Options: pio, otg (peripheral+host), [eps=16]
Peripheral address: 00
Root port status: 00000100

dmesg | grep usb gives lines included in the attached file.

The board includes a 1k5 pull up resistor on the D+ line.

The module should communicate through cdc_acm driver interface, but ls /dev/ttyA* returns nothing.

Note : A demo version of our board including only the CC2531 part (same schematic for this part) is correctly detected (/dev/ttyACM0 found) when connected to the USB1 port of an AM335x_evm SK sitara kit.

The linux system on our board is quite similar compared to the one present on the sitara kit.

When the D+ line is shorten to GND, following messages are displayed :

[  349.345733] ti81xx_interrupt 1118: CAUTION: musb1: Babble Interrupt Occured
[  349.353759] musb_stage0_irq 817: unhandled DISCONNECT transition (a_idle)
[  349.360870] musb_stage0_irq 817: unhandled DISCONNECT transition (a_idle)
[  349.368133] musb_babble_workaround 921: Babble: devtcl(90)Restarting musb....

But nothing is displayed when the short is removed, as if the AM3352 didn't detect the rising edge on D+

I don't understand what happens and I'm looking for new tracks to explore...

Thank you all for your future help.

 

 

  • 0
    TI__Guru**** 393215 points

    Hi Didier,

    Please post the schematic connections of the USB both on the AM335X side and the device side.

  • 0 in reply to Biser Gatchev-XID
    Intellectual 350 points

    Hi Biser.

    Thank you for replying quickly.

    Before posting my schematic, here are some notes about our hardware.

    I just read in the AM335x datasheet (chap. 16.3.7) that both USBx_ID and USBx_VBUS pins are importants for that detection phase.

    I watched our schematic and detected that our connections here are not as expected :

    USB1_VBUS is connected directly to 3.3V

    USB1_ID is not connected at all

    As I understood in the datasheet, the processeur senses USB1_VBUS to see if a voltage greater than 4.4v is present. If no, the controller doesn't start listenning to new connection on the bus. Do you confirm ?

    If true, is there any other solutions ?

    I saw some comments about the DEVCTL[SESSION] bit in the datasheet, that says that this bit can be used to tell the controller to start operating as a host. Could it be used to override this kind of hardware problem, at least, to check that the problem has been found ?

    Thanks

  • 0 in reply to didier cadiou
    TI__Guru**** 393215 points

    Hi Didier,

    I see that you are looking in the right direction. For Host mode operation the USB needs:

    USB_ID to be tied to GND.
    USB_VBUS should be tied to the VBUS power supply after a power switch, that's controlled by USB_DRVVBUS.
    Since in your case both devices are on-board you can replace the power switch with a simple transistor circuit, similar to this:
  • 0 in reply to Biser Gatchev-XID
    Intellectual 350 points

    Hi Biser.

     

    Thank you for this explanation and the schematic.

    Before doing a board redesign, is there any software solution to configure the AM3352 (register DEVCTRL for instance), to be able to communicate with our module, despite our schematic error ?

    Best regards

  • 0 in reply to didier cadiou
    TI__Guru**** 167191 points

    Didier,

    To workaround the USB1_ID pin issue in your design, you can use the following patch.

    diff --git a/drivers/usb/musb/ti81xx.c b/drivers/usb/musb/ti81xx.c
index 74288a8..fcee071 100644
--- a/drivers/usb/musb/ti81xx.c
+++ b/drivers/usb/musb/ti81xx.c
@@ -1244,7 +1244,6 @@ int ti81xx_musb_set_mode(struct musb *musb, u8 musb_mode)
                regval = musb_readl(reg_base, USB_MODE_REG);
 
                regval &= ~USBMODE_USBID_HIGH;
-               if (usbid_sw_ctrl && cpu_is_ti816x())
                        regval |= USBMODE_USBID_MUXSEL;
 
                musb_writel(reg_base, USB_MODE_REG, regval);

    There is no way to workaround that USB1_VBUS tying to 3.3V. You either have to add the power switch as Biser recommended, or tie USB1_VBUS to 5.0V and use the following patch if you use SDK6.0 kernel 3.2. But please change 'id == 0' to 'id == 1' in the patch.

    http://e2e.ti.com/support/arm/sitara_arm/f/791/p/333490/1163908.aspx#1163908

  • 0 in reply to Bin Liu
    Intellectual 350 points

    Thank you Bin and Biser for all your answers.

    The situation is clear : We can't avoid a board redesign.

    Thank you again

    Best regards.

  • 0 in reply to didier cadiou
    Prodigy 190 points

    Hello Didier,

    in our first passage your wrote that you detected a /dev/ttyACM device. Have you already done any communication test from applications with the device ?. 

    We noticed some problems with the 3.12 kernel (additionals 0x00 bytes) which we didn't saw at other Linux platforms.

    (Kernel 3.2 didn't work at all).

    Kind reagrds

    Rainer

  • 0 in reply to Rainer Berns
    Intellectual 350 points

    Hi Rainer.

    We already succeeded in communicating with our module, but on a sitara EVM kit, with the module connected as an external peripheral with a standard USB cable.

    The kernel version used was the 3.2.0. We didn't notice communication problems at the USB level. Our application was able to drive our module as expected.

    An additionnal information : We made ourself the firmware integrated Inside the module.

    Best regards.

     

  • 0 in reply to didier cadiou
    Prodigy 190 points

    Hi Didier,

    thanks your response. This is strange. We use an Atmel Controller as USB device with an Atmel Framework.

    Maybe i need to test it with a different USB ttyACM device to find out what causes the problems.

    Regards