Hello Michele,
On 2012.01.17 11:00, michele.paolino wrote:
> libusb_clear_halt(cur_handle, ENDPOINT_BULK_OUT);
is there a reason you issue a clear_halt?
As its name indicate this call is intended to be used in case of a
transfer problem, so it's a bit unexpected there unless you expect a
previous call to fail. Does the same problem occur on the first transfer
if you remove the clear_halt?
> libusb_set_configuration(cur_handle, 1)
http://www.libusb.org/wiki/windows_backend#KnownRestrictions :
"WinUSB cannot be used to set a device configuration that is different
from the default one. This is a limitation of the Microsoft driver."
You should try to avoid using libusb_set_configuration on Windows (at
least as long as we only support WinUSB as a driver), unless you are
certain to select the default one.
> Are there known issues with windows x64?
Most of the development and testing of the Windows backend is done on
Windows x64 (if anything, it's the 32 bit version that is tested the
less), so x64 is not expected to present more problems than non x64.
I'll try to investigate this further when I have a chance.
Regards,
/Pete

Hi,
On Tue, Jan 17, 2012 at 11:50:22AM +0000, Pete Batard wrote:
> On 2012.01.17 11:00, michele.paolino wrote:
>
> > libusb_set_configuration(cur_handle, 1)
>
> http://www.libusb.org/wiki/windows_backend#KnownRestrictions :
> "WinUSB cannot be used to set a device configuration that is different
> from the default one. This is a limitation of the Microsoft driver."
>
> You should try to avoid using libusb_set_configuration on Windows (at
> least as long as we only support WinUSB as a driver), unless you are
> certain to select the default one.
Among other things, SET_CONFIGURATION resets the data toggle of
the endpoint to DATA0. However, SET_INTERFACE also should do it.
But since the question is about Cypress FX2, is this correctly
implemented in the FX2 firmware?
Does the device work with other OS or is Win7 x64 the only one tried?
HTH
Johannes

On Tue, 17 Jan 2012, Johannes Stezenbach wrote:
> Hi,
>
> On Tue, Jan 17, 2012 at 11:50:22AM +0000, Pete Batard wrote:
> > On 2012.01.17 11:00, michele.paolino wrote:
> >
> > > libusb_set_configuration(cur_handle, 1)
> >
> > http://www.libusb.org/wiki/windows_backend#KnownRestrictions :
> > "WinUSB cannot be used to set a device configuration that is different
> > from the default one. This is a limitation of the Microsoft driver."
> >
> > You should try to avoid using libusb_set_configuration on Windows (at
> > least as long as we only support WinUSB as a driver), unless you are
> > certain to select the default one.
>
> Among other things, SET_CONFIGURATION resets the data toggle of
> the endpoint to DATA0.
Why would anybody want to do that? Isn't it easier and simpler just to
keep using the endpoint's current data toggle value?
Alan Stern

On Tue, 17 Jan 2012, Johannes Stezenbach wrote:
> On Tue, Jan 17, 2012 at 10:42:53AM -0500, Alan Stern wrote:
> > On Tue, 17 Jan 2012, Johannes Stezenbach wrote:
> > >
> > > Among other things, SET_CONFIGURATION resets the data toggle of
> > > the endpoint to DATA0.
> >
> > Why would anybody want to do that? Isn't it easier and simpler just to
> > keep using the endpoint's current data toggle value?
>
> USB spec section 9.1.1.5 "Configured" requires it.
You misunderstood. I wasn't asking why you would want to put the
device into the Configured state; I was asking why you would want to
reset the endpoint's data toggle.
Although, come to think of it, why _would_ you want to put the device
into the Configured state? The only reason I can think of would be if
the operating system didn't already take care of that for you.
Alan Stern

On Tue, Jan 17, 2012 at 11:42:45AM -0500, Alan Stern wrote:
> On Tue, 17 Jan 2012, Johannes Stezenbach wrote:
>
> > On Tue, Jan 17, 2012 at 10:42:53AM -0500, Alan Stern wrote:
> > > On Tue, 17 Jan 2012, Johannes Stezenbach wrote:
> > > >
> > > > Among other things, SET_CONFIGURATION resets the data toggle of
> > > > the endpoint to DATA0.
> > >
> > > Why would anybody want to do that? Isn't it easier and simpler just to
> > > keep using the endpoint's current data toggle value?
> >
> > USB spec section 9.1.1.5 "Configured" requires it.
>
> You misunderstood. I wasn't asking why you would want to put the
> device into the Configured state; I was asking why you would want to
> reset the endpoint's data toggle.
That's what I mean, 9.1.1.5 requires the data toggle reset
when setting the configuration.
> Although, come to think of it, why _would_ you want to put the device
> into the Configured state? The only reason I can think of would be if
> the operating system didn't already take care of that for you.
It doesn't matter who calls SET_CONFIGURATION, what matters is
that HCD and device agree, otherwise the HCD will signal
an error. I mention it because I spent some time debugging
FX2 firmware and this was one of the issues causing mysterious
error returns.
However, my device is self powered, if the device is bus powered
and the configuration is set once after plug-in by the OS then you'll
never see this issue.
Johannes

On Tue, 17 Jan 2012, Johannes Stezenbach wrote:
> On Tue, Jan 17, 2012 at 11:42:45AM -0500, Alan Stern wrote:
> > On Tue, 17 Jan 2012, Johannes Stezenbach wrote:
> >
> > > On Tue, Jan 17, 2012 at 10:42:53AM -0500, Alan Stern wrote:
> > > > On Tue, 17 Jan 2012, Johannes Stezenbach wrote:
> > > > >
> > > > > Among other things, SET_CONFIGURATION resets the data toggle of
> > > > > the endpoint to DATA0.
> > > >
> > > > Why would anybody want to do that? Isn't it easier and simpler just to
> > > > keep using the endpoint's current data toggle value?
> > >
> > > USB spec section 9.1.1.5 "Configured" requires it.
> >
> > You misunderstood. I wasn't asking why you would want to put the
> > device into the Configured state; I was asking why you would want to
> > reset the endpoint's data toggle.
>
> That's what I mean, 9.1.1.5 requires the data toggle reset
> when setting the configuration.
Sorry, I can't follow what you're saying at all.
Yes, 9.1.1.5 requires the device to reset its data toggles when it
receives a Set-Config request. That doesn't explain why you would want
to send a Set-Config request in the first place, or why you would want
to reset the data toggles.
> > Although, come to think of it, why _would_ you want to put the device
> > into the Configured state? The only reason I can think of would be if
> > the operating system didn't already take care of that for you.
>
> It doesn't matter who calls SET_CONFIGURATION, what matters is
> that HCD and device agree, otherwise the HCD will signal
> an error. I mention it because I spent some time debugging
> FX2 firmware and this was one of the issues causing mysterious
> error returns.
How would the HCD and the device get out of agreement to begin with?
If they agree all along, there's no reason to change the toggle
setting.
> However, my device is self powered, if the device is bus powered
> and the configuration is set once after plug-in by the OS then you'll
> never see this issue.
Even with a self-powered device, how would the HCD and the device get
out of agreement on a toggle value? A bug in the device firmware,
perhaps? I have noticed that many firmwares seem to have trouble
handling Set-Interface requests. They crash, or they forget to clear
the data toggles (in spite of the fact that 9.1.1.5 requires them to do
so).
Alan Stern

On Tue, Jan 17, 2012 at 02:49:36PM -0500, Alan Stern wrote:
> On Tue, 17 Jan 2012, Johannes Stezenbach wrote:
> >
> > That's what I mean, 9.1.1.5 requires the data toggle reset
> > when setting the configuration.
>
> Sorry, I can't follow what you're saying at all.
>
> Yes, 9.1.1.5 requires the device to reset its data toggles when it
> receives a Set-Config request. That doesn't explain why you would want
> to send a Set-Config request in the first place, or why you would want
> to reset the data toggles.
Required or not, one can send Set-Config requests as often as wanted.
What matters is that the FX2 firmware needs to handle it correctly.
The OP quoted this sequence of calls:
libusb_set_configuration(cur_handle, 1)
libusb_claim_interface(cur_handle, 0)
libusb_set_interface_alt_setting(cur_handle,0,0)
Thus I remembered about this issue because my libusb based driver
did something similar which caused intermittent errors
and eventually was tracked down as the FX2 firmware bug I'm talking about.
> > > Although, come to think of it, why _would_ you want to put the device
> > > into the Configured state? The only reason I can think of would be if
> > > the operating system didn't already take care of that for you.
> >
> > It doesn't matter who calls SET_CONFIGURATION, what matters is
> > that HCD and device agree, otherwise the HCD will signal
> > an error. I mention it because I spent some time debugging
> > FX2 firmware and this was one of the issues causing mysterious
> > error returns.
>
> How would the HCD and the device get out of agreement to begin with?
> If they agree all along, there's no reason to change the toggle
> setting.
>
> > However, my device is self powered, if the device is bus powered
> > and the configuration is set once after plug-in by the OS then you'll
> > never see this issue.
>
> Even with a self-powered device, how would the HCD and the device get
> out of agreement on a toggle value? A bug in the device firmware,
> perhaps? I have noticed that many firmwares seem to have trouble
> handling Set-Interface requests. They crash, or they forget to clear
> the data toggles (in spite of the fact that 9.1.1.5 requires them to do
> so).
Hrm, this subthread _is_ about FX2 firmware bugs.
FX2 does not reset the data toggles unless either
the firmware does it or power is removed. Host and FX2 get
out of sync when host issues SET_CONFIGURATION and thus
resets its data toggle, but FX2 firmware does not.
It should be noted that FX2 does not reset the data toggles
by itself during enumeration or due to USB reset, it has
to be handled by firmware. Thus if an FX2 device is in
an active hub which does not support switching port power
the issue may also arise.
Johannes

Hi, Thank you for your answers,
On Tue, Jan 17, 2012 at 1:37 PM, Johannes Stezenbach <js@...> wrote:
> Hi,
>
> On Tue, Jan 17, 2012 at 11:50:22AM +0000, Pete Batard wrote:
> > On 2012.01.17 11:00, michele.paolino wrote:
> >
> > > libusb_set_configuration(cur_handle, 1)
> >
> > http://www.libusb.org/wiki/windows_backend#KnownRestrictions :
> > "WinUSB cannot be used to set a device configuration that is different
> > from the default one. This is a limitation of the Microsoft driver."
> >
> > You should try to avoid using libusb_set_configuration on Windows (at
> > least as long as we only support WinUSB as a driver), unless you are
> > certain to select the default one.
>
> Among other things, SET_CONFIGURATION resets the data toggle of
> the endpoint to DATA0. However, SET_INTERFACE also should do it.
> But since the question is about Cypress FX2, is this correctly
> implemented in the FX2 firmware?
>
I have commented the line in wich I call libusb_set_configuration and
libusb_clear_halt. Now debug output is similar to the previous. On the
other hand now there is a line that says:
libusb:debug [libusb_handle_events_timeout_completed] doing our own event
handling
About Cypress FX2, I have configured EP2 (and EP6) FIFO in AUTO mode. I
would like to be able to write to FX2 through EP2 and read through EP6. I
used as fw.c (the file that describes the framework) the original one. In
the other C File the only modified function is TD_Init as below. Maybe I'm
wrong, but I think that FX2 is properly configured (I have read the manual
thousands of times :-( ). I have removed SYNCDELAY between every line to
reduce the numbers of lines:
void TD_Init( void )
{ REVCTL=0x03;
SYNCDELAY;
CPUCS = 0x10;
EP6FIFOPFH=0x19;
EP6FIFOPFL=0xFA;
PINFLAGSAB = 0x6A;
PINFLAGSCD = 0xC8;
IFCONFIG = 0x43;
FIFORESET = 0x80; // activate NAK-ALL
FIFORESET = 0x02; // reset, FIFO 2
FIFORESET = 0x04; // reset, FIFO 4
FIFORESET = 0x06; // reset, FIFO 6
FIFORESET = 0x08; // reset, FIFO 8
FIFORESET = 0x00; // deactivate NAK-ALL
EP2CFG = 0xA2;
EP6CFG = 0xE0;
EP2FIFOCFG = 0x11; // AUTOOUT=1, WORDWIDE=1
OUTPKTEND=0x82;
OUTPKTEND=0x82;
EP6FIFOCFG = 0x09; // AUTOIN=1, ZEROLENIN=1, WORDWIDE=1
EP6AUTOINLENH = 0x02; // Auto-commit 512-byte packets
EP6AUTOINLENL = 0x00;
REVCTL=0x00; }
>
> Does the device work with other OS or is Win7 x64 the only one tried?
>
Sincerely I'm working with Seven x64 and is the only one I tried. I prefer
(for this project) to use Windows because I have a lot of work done in
VisualStudio.
>
>
> HTH
> Johannes
>
>
> ------------------------------------------------------------------------------
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> _______________________________________________
> Libusb-devel mailing list
> Libusb-devel@...
> https://lists.sourceforge.net/lists/listinfo/libusb-devel
>
>
>
Regards
--
Michele Paolino

On Tue, Jan 17, 2012 at 03:51:14PM +0100, michele.paolino wrote:
> About Cypress FX2, I have configured EP2 (and EP6) FIFO in AUTO mode. I
> would like to be able to write to FX2 through EP2 and read through EP6. I
> used as fw.c (the file that describes the framework) the original one. In
> the other C File the only modified function is TD_Init as below. Maybe I'm
> wrong, but I think that FX2 is properly configured (I have read the manual
> thousands of times :-( ). I have removed SYNCDELAY between every line to
> reduce the numbers of lines:
>
> void TD_Init( void )
I'm not familiar with Keil tools, I worked on Linux with sdcc + fx2lib.
The relevant part is that the SET_CONFIGURATION handler somehow
sets the appropriate bits in the TOGCTL register. The
examples from Cypress website (which include VendAx used by fxload
to program the EEPROM) fail to do it, they only do it in
CLEAR_FEATURE(EP_HALT).
http://www.cypress.com/?rID=14321
HTH
Johannes

michele.paolino wrote:
>
> About Cypress FX2, I have configured EP2 (and EP6) FIFO in AUTO mode.
> I would like to be able to write to FX2 through EP2 and read through
> EP6. I used as fw.c (the file that describes the framework) the
> original one. In the other C File the only modified function is
> TD_Init as below. Maybe I'm wrong, but I think that FX2 is properly
> configured (I have read the manual thousands of times :-( ).
"Auto" mode merely means that the packet will be sent as soon as there
are enough bytes in the FIFO. However, someone, somewhere still has to
put bytes in the FIFO. I don't see that you are doing that. If you
want to do loopback, then you have to have FX2 code that copies from the
endpoint 2 FIFO into the endpoint 6 FIFO.
> I have removed SYNCDELAY between every line to reduce the numbers of
> lines:
Remember that only certain registers need the SYNCDELAY. The list is
long, but it does not include every register.
--
Tim Roberts, timr@...
Providenza & Boekelheide, Inc.

On Tue, Jan 17, 2012 at 6:55 PM, Tim Roberts <timr@...> wrote:
> michele.paolino wrote:
> >
> > About Cypress FX2, I have configured EP2 (and EP6) FIFO in AUTO mode.
> > I would like to be able to write to FX2 through EP2 and read through
> > EP6. I used as fw.c (the file that describes the framework) the
> > original one. In the other C File the only modified function is
> > TD_Init as below. Maybe I'm wrong, but I think that FX2 is properly
> > configured (I have read the manual thousands of times :-( ).
>
> "Auto" mode merely means that the packet will be sent as soon as there
> are enough bytes in the FIFO. However, someone, somewhere still has to
> put bytes in the FIFO. I don't see that you are doing that. If you
> want to do loopback, then you have to have FX2 code that copies from the
> endpoint 2 FIFO into the endpoint 6 FIFO.
>
> > I have removed SYNCDELAY between every line to reduce the numbers of
> > lines:
>
> Remember that only certain registers need the SYNCDELAY. The list is
> long, but it does not include every register.
>
I want to use FX2 to send and reveive packets between Pc and FPGA. For test
purposes I think that also loopback could be fine. I understood that Auto
mode give the possibility to send/receive packets automatically, without
the firmware aid...but clearly I'm wrong. So I'll take a look to my
firmware.
Thank you for your useful advices.
> --
> Tim Roberts, timr@...
> Providenza & Boekelheide, Inc.
>
>
>
> ------------------------------------------------------------------------------
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> _______________________________________________
> Libusb-devel mailing list
> Libusb-devel@...
> https://lists.sourceforge.net/lists/listinfo/libusb-devel
>
>
>
--
Michele Paolino

michele.paolino wrote:
>
> I want to use FX2 to send and reveive packets between Pc and FPGA. For
> test purposes I think that also loopback could be fine. I understood
> that Auto mode give the possibility to send/receive packets
> automatically, without the firmware aid...but clearly I'm wrong. So
> I'll take a look to my firmware.
No, it's not THAT automatic. Each endpoint has a FIFO. For an IN
endpoint (device-to-host), somebody has to shove data into that FIFO.
The FX2's USB engine will not send a packet out from a FIFO until the
packet is "committed". Until then, the data just sits in the FIFO.
What "auto" mode does is say "as soon as there are N bytes of data in
the FIFO, it should automatically be committed."
Each endpoint has its own completely separate FIFO. The data you are
getting on your OUT endpoint (host-to-device) is going into a separate
area of memory than the data you are sending on your IN endpoint. To do
loopback, someone, somewhere has to copy that data. I thought Cypress
has some sample firmware in their development kit that did that.
If you already have your hardware with your FPGA attached, it might be
easier to write a little Verilog to do the copying. That would also let
you check your slave mode handling. Remember that the CPU in the FX2 is
unbelievably slow -- at the maximum clock rate, it runs 3 or 4 MIPS.
Copying 512 bytes requires half a millisecond, which is 4 microframes.
--
Tim Roberts, timr@...
Providenza & Boekelheide, Inc.

My problem was solved by writing a new FX2 firmware. In particular, I was
inspired by FX2 examples firmware (Bulk-src) installed automatically with
Cypress tools.
Thank you to all, specially to Tim, for your advices.
Regards
On Wed, Jan 18, 2012 at 7:21 PM, Tim Roberts <timr@...> wrote:
> michele.paolino wrote:
> >
> > I want to use FX2 to send and reveive packets between Pc and FPGA. For
> > test purposes I think that also loopback could be fine. I understood
> > that Auto mode give the possibility to send/receive packets
> > automatically, without the firmware aid...but clearly I'm wrong. So
> > I'll take a look to my firmware.
>
> No, it's not THAT automatic. Each endpoint has a FIFO. For an IN
> endpoint (device-to-host), somebody has to shove data into that FIFO.
> The FX2's USB engine will not send a packet out from a FIFO until the
> packet is "committed". Until then, the data just sits in the FIFO.
> What "auto" mode does is say "as soon as there are N bytes of data in
> the FIFO, it should automatically be committed."
>
> Each endpoint has its own completely separate FIFO. The data you are
> getting on your OUT endpoint (host-to-device) is going into a separate
> area of memory than the data you are sending on your IN endpoint. To do
> loopback, someone, somewhere has to copy that data. I thought Cypress
> has some sample firmware in their development kit that did that.
>
> If you already have your hardware with your FPGA attached, it might be
> easier to write a little Verilog to do the copying. That would also let
> you check your slave mode handling. Remember that the CPU in the FX2 is
> unbelievably slow -- at the maximum clock rate, it runs 3 or 4 MIPS.
> Copying 512 bytes requires half a millisecond, which is 4 microframes.
>
> --
> Tim Roberts, timr@...
> Providenza & Boekelheide, Inc.
>
>
>
> ------------------------------------------------------------------------------
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> _______________________________________________
> Libusb-devel mailing list
> Libusb-devel@...
> https://lists.sourceforge.net/lists/listinfo/libusb-devel
>
>
>
--
Michele Paolino