On Wed, 18 01:54 , Pete Batard wrote:
>
> Thanks for the info. I was hoping I could get my hands on an FX2 to
> possibly add an upload feature to xusb that can be used against both FX2
> and FX3 (as the FX2 is more widespread), but I doubt I'll have a chance
> to do that, so I'll probably just
On 2012.07.18 00:02, Markus wrote:
> As I just came over it again, I feel obliged to mention that
> this patch is derived from a patch for fx2load posted to the
> Cypress FX3 forum (amongst others). See this URL for reference:
>
> http://comments.gmane.org/gmane.linux.hotplug.devel/17427
Thanks fo
On Mon, 18 18:03 , Pete Batard wrote:
> > I created ticket #29 [1] to add your patch against the 1.0.13 milestone,
>
> [1] https://sourceforge.net/apps/trac/libusbx/ticket/29
>
As I just came over it again, I feel obliged to mention that
this patch is derived from a patch for fx2load posted to t
On Tue, Jun 19, 2012 at 8:08 AM, Markus wrote:
> On Tue, 19 07:35 , Xiaofan Chen wrote:
>> > http://argh.target23.de/data/fx3.png
>>
>> That still shows High Speed USB, have you tried it with
>> the USB 3.0 SuperSpeed port?
>>
>
> The device is attached to a SuperSpeed hostcontroller here.
> But
On Tue, 19 07:35 , Xiaofan Chen wrote:
> > http://argh.target23.de/data/fx3.png
>
> That still shows High Speed USB, have you tried it with
> the USB 3.0 SuperSpeed port?
>
The device is attached to a SuperSpeed hostcontroller here.
But apparantly, the FX3 bootloader firmware is coming up as
a
On Tue, Jun 19, 2012 at 3:24 AM, Markus wrote:
> After starting to integrate it into cycfx2prog
> (http://www.triplespark.net/elec/periph/USB-FX2/software/)
> I realized that I lack the time to do this cleanly at the moment.
cycfx2prog works under Linux and Windows. And I like it better
than fxlo
On Mon, Jun 18, 2012 at 11:30 PM, Markus wrote:
> I managed to bring the FX3 firmware upload into a working state
> now. Instead of making it a commandline tool on its own, I decided
> to diff it against xusb.c, as the amount of code is limited:
>
> http://argh.target23.de/data/xusb.diff
> http://
On Mon, 18 18:01 , Pete Batard wrote:
>
> Still, I agree with Peter that having separate samples dedicated to
> FX2/FX3 devices would be a plus, as there's a lot more we could do with
> those besides uploading firmware. But if you don't have much of a chance
> or time to produce one, using xus
On Mon, 18 18:43 , Peter Stuge wrote:
>
> I guess that the fx2load package would welcome a patch! :)
There's already a patch for it:
http://www.cypress.com/?app=forum&id=167&rID=53996
> If you prefer to add an fx3load example to libusb instead then I
> would welcome that, but on the other han
> I created ticket #29 [1] to add your patch against the 1.0.13 milestone,
[1] https://sourceforge.net/apps/trac/libusbx/ticket/29
/Pete
--
Live Security Virtual Conference
Exclusive live event will cover all the ways to
On 2012.06.18 17:43, Peter Stuge wrote:
> Markus wrote:
>> I managed to bring the FX3 firmware upload into a working state now.
>> Instead of making it a commandline tool on its own, I decided
>> to diff it against xusb.c
>
> I guess that the fx2load package would welcome a patch! :)
>
> If you pre
Markus wrote:
> I managed to bring the FX3 firmware upload into a working state now.
> Instead of making it a commandline tool on its own, I decided
> to diff it against xusb.c
I guess that the fx2load package would welcome a patch! :)
If you prefer to add an fx3load example to libusb instead th
Hi there,
I managed to bring the FX3 firmware upload into a working state
now. Instead of making it a commandline tool on its own, I decided
to diff it against xusb.c, as the amount of code is limited:
http://argh.target23.de/data/xusb.diff
http://argh.target23.de/data/fx3.png
Starting out deve
Thanks for all your suggestions first. USB Monitor seems to fit
my needs quite well, though I've been running the device only on
a 2.0 port today. Either there's no support for USB 3.0 yet or I
was unable to spot it (but I can test my case with USB 2.0 as
well).
I've also tried USB 2.0 ports, to n
Markus wrote:
> Thanks, Pete. As Wireshark doesn't capture USB on Windows, it
> looks as I'll have to resort to a proprietary tool.
>
> Can you (or somebody else reading the list) recommend something worthwhile in
> a price range < 500$ ?
I've used USB Monitor from HHD Software for many years.
On Wed, Jun 13, 2012 at 6:29 AM, Xiaofan Chen wrote:
> On Wed, Jun 13, 2012 at 9:17 PM, Markus wrote:
> > On Wed, 13 13:24 , Pete Batard wrote:
> >>
> >> When achievable, being able to have a look at the data being sent on the
> >> bus usually pays off, especially if you're not sure where to lo
Hi Markus,
On 2012.06.12 15:32, Markus wrote:
> I'd like to replace a vendor tool for firmware download
> to a developement board by using libusbx.
OK.
> As of now, I can read and write memory by using vendor request
> control transfers. According to the manufacturer this is the way
> to go for
On 2012.06.14 15:43, Markus wrote:
> when looking at the URBs, I don't
> spot any difference except for the address.
> (...)
> I'm getting increasingly convinced that it's a device issue.
Looks that way.
If the values you get in the Control requests are the one you populated
in the app, there's
On Wed, 13 13:24 , Pete Batard wrote:
> Well, all I can say is that we seem to be getting a stall report by
> WinUSB indeed.
...
> If you see the expected >0x4000 wValue, and the rest of the request is
> the same, then the problem is likely to be with the device rather than
> libusbx or WinUSB.
On Thu, Jun 14, 2012 at 4:30 AM, Markus wrote:
> On Wed, 13 11:55 , Tim Roberts wrote:
>>
>> OK, please allow me to ask a foolish question. Do you really have an
>> FX3, and not an FX2?
>>
>
> You may; I might ask the one or other foolish question too on
> this list in the future.
>
> But if it
On Wed, 13 11:55 , Tim Roberts wrote:
>
> OK, please allow me to ask a foolish question. Do you really have an
> FX3, and not an FX2?
>
You may; I might ask the one or other foolish question too on
this list in the future.
But if it was an FX2 I would spend my time with something more
meanin
Markus wrote:
> int CypressFX3Device::WriteRAM(size_t addr,
> const unsigned char *data, size_t nbytes)
OK, please allow me to ask a foolish question. Do you really have an
FX3, and not an FX2? The FX2 only has 16kB of RAM, which is where you
are hitting the problem. The FX3 is supposed to h
Hi,
On 06/13/2012 03:17 PM, Markus wrote:
> On Wed, 13 13:24 , Pete Batard wrote:
>>
>> When achievable, being able to have a look at the data being sent on the
>> bus usually pays off, especially if you're not sure where to look to
>> find out where the problem comes from.
>>
>
> Thanks, Pete. A
On Wed, Jun 13, 2012 at 9:17 PM, Markus wrote:
> On Wed, 13 13:24 , Pete Batard wrote:
>>
>> When achievable, being able to have a look at the data being sent on the
>> bus usually pays off, especially if you're not sure where to look to
>> find out where the problem comes from.
>>
>
> Thanks, Pe
On Wed, 13 13:24 , Pete Batard wrote:
>
> When achievable, being able to have a look at the data being sent on the
> bus usually pays off, especially if you're not sure where to look to
> find out where the problem comes from.
>
Thanks, Pete. As Wireshark doesn't capture USB on Windows, it
lo
On 2012.06.13 12:46, Markus wrote:
> Here's the log of the last good control transfer and the
> consecutive one that's failing:
>
> [ 3.130939] [15d8] libusbx: debug [windows_transfer_callback] handling
> I/O completion with errcode 31
> [ 3.130939] [15d8] libusbx: debug [windows_transfer_
On Wed, 13 10:36 , Pete Batard wrote:
> > I don't see any debug messages (though I enabled the libusbx debug
> > facility in my code, level 3).
>
> Try level 4. 4 is the level to set for debug, not 3.
Thanks for the reminder... My bad. I' running the RC from yesterday
BTW.
Here's the log of th
On 2012.06.12 22:18, Markus wrote:
> I don't see any debug messages (though I enabled the libusbx debug
> facility in my code, level 3).
Try level 4. 4 is the level to set for debug, not 3.
If you're using a version earlier than 1.0.11.10519, you will also have
to compile with either --enable-de
On Tue, 12 10:06 , Tim Roberts wrote:
>
> > wValue (LSW) and wIndex (MSW) make up the address offset to write
> > the data to within device memory.
>
> Are you sure you have the ordering correct? (It probably is, because
> that lets those two fields be treated as a single little-endian dword
Markus wrote:
> As of now, I can read and write memory by using vendor request
> control transfers. According to the manufacturer this is the way
> to go for firmware dump and download.
That's a common mechanism.
> wValue (LSW) and wIndex (MSW) make up the address offset to write
> the data t
30 matches
Mail list logo
