From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11525 invoked by alias); 1 Jun 2009 09:13:25 -0000 Received: (qmail 11471 invoked by uid 22791); 1 Jun 2009 09:13:24 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from alicia.2020media.com (HELO alicia.2020mail.com) (212.124.192.215) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 01 Jun 2009 09:13:15 +0000 Received: from [212.124.199.38] (helo=[192.168.0.2]) by alicia.2020mail.com with esmtp (Exim 4.30; FreeBSD) id 1MB3Zr-000B8y-RZ; Mon, 01 Jun 2009 10:13:07 +0100 Message-ID: <4A239BA5.1050601@zynaptic.com> Date: Mon, 01 Jun 2009 09:13:00 -0000 From: Chris Holgate User-Agent: Thunderbird 2.0.0.19 (X11/20081227) MIME-Version: 1.0 To: GaurangT CC: ecos-devel@ecos.sourceware.org Subject: Re: USB test code problem with stm32 eval board References: <23810900.post@talk.nabble.com> In-Reply-To: <23810900.post@talk.nabble.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact ecos-devel-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: ecos-devel-owner@ecos.sourceware.org X-SW-Source: 2009-06/txt/msg00001.txt.bz2 GaurangT wrote: > Hi, > I want to test USB support Added for STM32 in eCos. For that i have > added stm32-usb-20090519.epk pacakge and got "ST STM3210E USB EVAL board" in > templates and able to add STM32 USB driver and it compiles fine. > > Now i am testing to test code of give in > package/io/usb/slave/tests/usbtraget.c.it compiles fine but when i run this > code following output on hyper terminal. > > STM32 USB : Setting USB device address = 1 > > and windows to ask install red hat ecos test software or driver install. > > plz how to test stm32 usb driver? It's in the manual... http://ecos.sourceware.org/docs-latest/ref/usbs-testing.html Unfortunately, the one testcase which is provided by default (bulk-boundaries) behaves a bit oddly on my system - which I'm inclined to put down to changes in the way Linux usbfs behaves since the original was written. When running the bulk-boundaries test, incoming transfers are treated as _not_ having zero length packet termination and outgoing transfers _do_ insert zero length packet termination. This behaviour really should be consistent between in and out transfers. I've not done much more investigation myself, since I've been using my proprietary class driver for testing - but I'm sure that a bit of tweaking to the TCL should get it to behave. If this were a low level Linux driver, this would be achievable by: 1) Forcing zero length packet termination on IN endpoints by issuing an URB with an oversized buffer so that all incoming packets are treated as short. Or... 2) Disabling zero length packet termination on OUT endpoints. Chris.