Author Topic: Unstable USB connetion  (Read 110 times)

jlamp

  • Active Member
  • *
  • Posts: 14
Unstable USB connetion
« on: June 06, 2018, 03:51:10 PM »
Hi,

I have the TE0720-03-1CFA module with TE0706 Carrier and I have been experiencing strange USB behavior when I try to connect an Asus Xtion Camera to the USB port.

Here the log example and the differences when I plug and unplug a Rii KEYBOARD WIRELESS RT-MWK01+ and Asus Xtion Camera with the reference image.

Code: [Select]

// Plug Rii Keyboard
root@plnx_arm:~# usb 1-1: new full-speed USB device number 2 using ci_hdrc
input:   Mini Keyboard as /devices/soc0/amba/e0002000.usb/ci_hdrc.0/usb1/1-1/1-1:1.0/0003:1997:2433.0001/input/inp0
hid-generic 0003:1997:2433.0001: input: USB HID v1.01 Keyboard [  Mini Keyboard] on usb-ci_hdrc.0-1/input0
input:   Mini Keyboard as /devices/soc0/amba/e0002000.usb/ci_hdrc.0/usb1/1-1/1-1:1.1/0003:1997:2433.0002/input/inp1
hid-generic 0003:1997:2433.0002: input: USB HID v1.01 Mouse [  Mini Keyboard] on usb-ci_hdrc.0-1/input1

// Unplug the keyboard
usb 1-1: USB disconnect, device number 2

// Plug the keyboard again
usb 1-1: new full-speed USB device number 3 using ci_hdrc
input:   Mini Keyboard as /devices/soc0/amba/e0002000.usb/ci_hdrc.0/usb1/1-1/1-1:1.0/0003:1997:2433.0003/input/inp2
hid-generic 0003:1997:2433.0003: input: USB HID v1.01 Keyboard [  Mini Keyboard] on usb-ci_hdrc.0-1/input0
input:   Mini Keyboard as /devices/soc0/amba/e0002000.usb/ci_hdrc.0/usb1/1-1/1-1:1.1/0003:1997:2433.0004/input/inp3
hid-generic 0003:1997:2433.0004: input: USB HID v1.01 Mouse [  Mini Keyboard] on usb-ci_hdrc.0-1/input1

// Unplug it again
usb 1-1: USB disconnect, device number 3

// Plug the Asus Xtion Camera
usb 1-1: new high-speed USB device number 4 using ci_hdrc

//Unplug Asus Xtion Camera
???Nothing happens, USB is not disconnecting

And if I type lsusb command after unplug  the device still remains there!

Code: [Select]
root@plnx_arm:~# lsusb
Bus 001 Device 004: ID 1d27:0601  <- Astra camera
Bus 001 Device 001: ID 1d6b:0002

It seems that USB gets stuck in this case and is not updating.

Also sometimes when I unplug the camera I can see the USB disconnect message but this is very aleatory and I need the camera USB connection to be stable for my application.

Can someone point me in the right direction and help me debugging this issue?

Thank you very much,

Jorge

JH

  • Sr. Member
  • ****
  • Posts: 483
Re: Unstable USB connetion
« Reply #1 on: June 07, 2018, 08:53:35 AM »
Hi,
which reference image? the newest one?
but I think this can be a driver problem. Reference designs are only configured with basic drivers, it can be that you need special driver for this camera.
brJohn

jlamp

  • Active Member
  • *
  • Posts: 14
Re: Unstable USB connetion
« Reply #2 on: June 14, 2018, 05:29:42 PM »
Hi John,

Yes the reference image is the newest one, the one you provide.

I have created a custom image using Yocto and I am experiencing the same behavior with the module. But when I tried  it in the zc702 development board the camera works without any problem so I think that the problem is more hardware or device-tree problem (I have reused the root file system and the kernel in both cases) than drivers.

Comparing the device-trees I have seen that zc702 uses pinctrl:

Code: [Select]
pinctrl_usb0_default: usb0-default {
mux {
groups = "usb0_0_grp";
function = "usb0";
};

conf {
groups = "usb0_0_grp";
slew-rate = <0>;
io-standard = <1>;
};

conf-rx {
pins = "MIO29", "MIO31", "MIO36";
bias-high-impedance;
};

conf-tx {
pins = "MIO28", "MIO30", "MIO32", "MIO33", "MIO34",
       "MIO35", "MIO37", "MIO38", "MIO39";
bias-disable;
};
};

Do I need to add them?

From Hardware side I see that the used usb chip is USB3320 and the schematic are very similar but the SOM uses a CPLD for the USB Reset could be this a problem?

This are for now two options that come to my mind to solve the problem but any help would be very appreciated.

Thank you very much for your help,

Jorge


JH

  • Sr. Member
  • ****
  • Posts: 483
Re: Unstable USB connetion
« Reply #3 on: June 15, 2018, 02:13:47 PM »
Hi,
you must try out. I didn't have this camera, so that I can't try out on my place.
At the moment I think it's not a reset problem. More Kernel and Device tree configuration.

pinctrl device tree entry seem to be ok for TE0720,  (TE0720 used also USB0 with MIO 28...39, so values should be work). But you must also check kernel config changes from zc702. or if they add something else which is needed for this camera (rootfs...).

Our Linux used default petalinux with our HDF import and additional changes listet here:
brJohn



jlamp

  • Active Member
  • *
  • Posts: 14
Re: Unstable USB connetion
« Reply #4 on: June 18, 2018, 10:23:31 AM »
Hi John,

Kernel config is the same in both boards and also the rootfs, I created them for the TE0720 and seeing that I had no success I put the same in zc702 SDCard so I don't think the problem is here.

Another question, why I need to add

Code: [Select]
    /*
     * Reset pulse to USB PHY
         */
        Status = XEmacPs_PhyWrite(&Emac, 0x1A,  7, 0x0010); if(Status != XST_SUCCESS){ return XST_FAILURE; }
        Status = XEmacPs_PhyWrite(&Emac, 0x1A,  7, 0x0000); if(Status != XST_SUCCESS){ return XST_FAILURE; }

code in FSBL to recognize the USB? I dont' see it in the zc702 board.

Thank you very much,

Jorge

jlamp

  • Active Member
  • *
  • Posts: 14
Re: Unstable USB connetion
« Reply #5 on: June 18, 2018, 10:52:51 AM »
I have also created a small program to reset the USB

Code: [Select]
#include <stdio.h>
#include <fcntl.h>  // cor open
#include <unistd.h> // for close
#include <errno.h>
#include <sys/ioctl.h>
#include <linux/usbdevice_fs.h>

void main(int argc, char **argv){

        const char *filename;
        int fd;
        filename = argv[1];

        fd = open(filename, O_WRONLY);
        ioctl(fd, USBDEVFS_RESET, 0);
        close(fd);

        return;

}

And when the USB gets stuck I execute it and I see how is reset

Code: [Select]
root@hros-trenz-som:~# ./reset /dev/bus/usb/001/002
usb 1-1: USB disconnect, device number 2
root@hros-trenz-som:~# usb 1-1: new high-speed USB device number 3 using ci_hdrc

So why is not a reset problem?

Thank you very much,

Jorge

JH

  • Sr. Member
  • ****
  • Posts: 483
Re: Unstable USB connetion
« Reply #6 on: June 18, 2018, 12:00:42 PM »
Hi,

i think only that's not a reset problem, because in the most cases it's a driver problem. But it can be also a reset problem. there are also much more reasons possible, which can effect this issue.
Did you checked the sources from same Vivado/Petalinux release, as you compared ZC702 and TE0720 petalinux configuration?

To your first post question:

Code: [Select]
    /*
     * Reset pulse to USB PHY
         */
        Status = XEmacPs_PhyWrite(&Emac, 0x1A,  7, 0x0010); if(Status != XST_SUCCESS){ return XST_FAILURE; }
        Status = XEmacPs_PhyWrite(&Emac, 0x1A,  7, 0x0000); if(Status != XST_SUCCESS){ return XST_FAILURE; }

Here FSBL write to CPLD and reset USB on power up. This is user code to get access to TE0720 CPLD, so it's not on zc702.

br
John

jlamp

  • Active Member
  • *
  • Posts: 14
Re: Unstable USB connetion
« Reply #7 on: June 18, 2018, 12:58:57 PM »
Hi,

Right now I am using Yocto to generate Linux distribution not Petalinux. With Yocto zc702 works but TE0720 gets stuck.

I have check Vivado project and the only difference between two boards is this MIO configuration part. Where the USB0 Reset is defined to use MIO7 zc702 but in the TE0720 not.



I can see this usb reset pin in the schematics of the zc702



In TE0720 I see that the USB reset is done through the CPLD,



So my question is how knows the CPLD when to do the reset when I unplug the camera from the USB connector and update the lsusb command?

Thanks,
Jorge

Modified, now images should be viewed
« Last Edit: June 18, 2018, 01:23:34 PM by jlamp »

Antti Lukats

  • Sr. Member
  • ****
  • Posts: 482
    • Trioflex
Re: Unstable USB connetion
« Reply #8 on: June 18, 2018, 03:15:29 PM »
USB PHY does not need the reset to be toggled after initial power up. So if it works it must work without any software controlled resets applied during operation.