usbpicprog-technical

[Usbpicprog-technical] win7 testing

[Francesco <f18...@ya...>]

Hi Frans,
   did you have a chance to test usbpicprog on Win7 64bit or WinVista 64bit?

I've recently upgraded to Win7 64bit and I cannot use UPP anymore...
in fact UPP doesn't detect the programmer anymore. This is a fault in
libusb-win32 which as the name implies has been coinceived for win32
only and not win64 :/
Tracing with MSVC++ debugger the execution of the program I found that
usb_get_busses() simply returns an empty object, i.e. libusb doesn't
seem to detect any USB device at all.

An important thing I should add is that I've firstly installed latest
0.3.0 upp EXE installer _after_ enabling test-signing drivers (with
the command "bcdedit /set testsigning on"). This allowed me to
successfully install the libusb driver but apparently it doesn't work.

I looked on the web and this is a summary of what I found:

1) libusb-win32 is maintained "only" by Sthepan Meyer; many people ask
for win64 support but so far libusb-win32 is for win32 only (and many
report that just installing libusb-win32 wreaks havoc your 64bit
system!! I was lucky ;)).
Stephan has been working on a libusb1 backend which uses the new
(introduced with WinVista) WinUSB API which allows to create user-mode
USB apps: http://libusb-win32.svn.sourceforge.net/viewvc/libusb-win32/trunk/libusb1/
 (btw this Stephan's new library seems to follow the same libusb-0.1
API of the main libusb-win32 project).

2) http://sourceforge.net/projects/openusb/    is a fork of libusb but
seems to be Mac and Linux only. I couldn't find much info about this
project (no mailing list or forums).

3) http://www.libusb.org promotes the use of the new stable 1.0 API
which has many advantages compared to the libusb-0.1 (maintained,
better docs, better design, MT safe, etc). Unfortunately there's still
no Windows backend for libusb-1.0. Josh Perry did some efforts
apparently successful to implement the backend using WinUSB (see
http://www.libusb.org/ticket/1) but he didn't post any patch AFAIK.

I think Win64 support is strategical and I'm planning to use USB for
other PIC-based projects I'm working on... so I'd be curious to know
if you have further info about this issue.

Thanks,
Francesco

[Usbpicprog-technical] win7 testing

[Francesco <fra...@gm...>]

Hi Frans,
    did you have a chance to test usbpicprog on Win7 64bit or WinVista 64bit?

I've recently upgraded to Win7 64bit and I cannot use UPP anymore...
in fact UPP doesn't detect the programmer anymore. This is a fault in
libusb-win32 which as the name implies has been coinceived for win32
only and not win64 :/
Tracing with MSVC++ debugger the execution of the program I found that
usb_get_busses() simply returns an empty object, i.e. libusb doesn't
seem to detect any USB device at all.

An important thing I should add is that I've firstly installed latest
0.3.0 upp EXE installer _after_ enabling test-signing drivers (with
the command "bcdedit /set testsigning on"). This allowed me to
successfully install the libusb driver but apparently it doesn't work.

I looked on the web and this is a summary of what I found:

1) libusb-win32 is maintained "only" by Sthepan Meyer; many people ask
for win64 support but so far libusb-win32 is for win32 only (and many
report that just installing libusb-win32 wreaks havoc your 64bit
system!! I was lucky ;)).
Stephan has been working on a libusb1 backend which uses the new
(introduced with WinVista) WinUSB API which allows to create user-mode
USB apps: http://libusb-win32.svn.sourceforge.net/viewvc/libusb-win32/trunk/libusb1/
  (btw this Stephan's new library seems to follow the same libusb-0.1
API of the main libusb-win32 project).

2) http://sourceforge.net/projects/openusb/    is a fork of libusb but
seems to be Mac and Linux only. I couldn't find much info about this
project (no mailing list or forums).

3) http://www.libusb.org promotes the use of the new stable 1.0 API
which has many advantages compared to the libusb-0.1 (maintained,
better docs, better design, MT safe, etc). Unfortunately there's still
no Windows backend for libusb-1.0. Josh Perry did some efforts
apparently successful to implement the backend using WinUSB (see
http://www.libusb.org/ticket/1) but he didn't post any patch AFAIK.

I think Win64 support is strategical and I'm planning to use USB for
other PIC-based projects I'm working on... so I'd be curious to know
if you have further info about this issue.

Thanks,
Francesco

Re: [Usbpicprog-technical] win7 testing

[Frans S. <fra...@gm...>]

Hi Francesco,

I don't have any 64 bit windows system, in fact the only windows that I
have is a 32 bit winXP (which I don't often use). Even though I have
never tested it on a 64 bit system, the libusb driver wizard (a tool
delivered with libusb-win32 to generate a device driver to let the
device communicate with libusb) does create a 64 bit driver. I think it
should work with a 32-bit binary on winXP-64 but I have never tested it.
For the time being let's investigate the possibilities.

Frans

On Sat, 2009-11-28 at 21:47 +0100, Francesco wrote:
> Hi Frans,
>     did you have a chance to test usbpicprog on Win7 64bit or WinVista 64bit?
> 
> I've recently upgraded to Win7 64bit and I cannot use UPP anymore...
> in fact UPP doesn't detect the programmer anymore. This is a fault in
> libusb-win32 which as the name implies has been coinceived for win32
> only and not win64 :/
> Tracing with MSVC++ debugger the execution of the program I found that
> usb_get_busses() simply returns an empty object, i.e. libusb doesn't
> seem to detect any USB device at all.
> 
> An important thing I should add is that I've firstly installed latest
> 0.3.0 upp EXE installer _after_ enabling test-signing drivers (with
> the command "bcdedit /set testsigning on"). This allowed me to
> successfully install the libusb driver but apparently it doesn't work.
> 
> I looked on the web and this is a summary of what I found:
> 
> 1) libusb-win32 is maintained "only" by Sthepan Meyer; many people ask
> for win64 support but so far libusb-win32 is for win32 only (and many
> report that just installing libusb-win32 wreaks havoc your 64bit
> system!! I was lucky ;)).
> Stephan has been working on a libusb1 backend which uses the new
> (introduced with WinVista) WinUSB API which allows to create user-mode
> USB apps: http://libusb-win32.svn.sourceforge.net/viewvc/libusb-win32/trunk/libusb1/
>   (btw this Stephan's new library seems to follow the same libusb-0.1
> API of the main libusb-win32 project).
> 
> 2) http://sourceforge.net/projects/openusb/    is a fork of libusb but
> seems to be Mac and Linux only. I couldn't find much info about this
> project (no mailing list or forums).
> 
> 3) http://www.libusb.org promotes the use of the new stable 1.0 API
> which has many advantages compared to the libusb-0.1 (maintained,
> better docs, better design, MT safe, etc). Unfortunately there's still
> no Windows backend for libusb-1.0. Josh Perry did some efforts
> apparently successful to implement the backend using WinUSB (see
> http://www.libusb.org/ticket/1) but he didn't post any patch AFAIK.
> 
> I think Win64 support is strategical and I'm planning to use USB for
> other PIC-based projects I'm working on... so I'd be curious to know
> if you have further info about this issue.
> 
> Thanks,
> Francesco
> 
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
> trial. Simplify your report design, integration and deployment - and focus on 
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Usbpicprog-technical mailing list
> Usb...@li...
> https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical

Re: [Usbpicprog-technical] win7 testing

[Francesco <f18...@ya...>]

Hi Frans,

2009/11/30 Frans Schreuder <fra...@gm...>:
> I don't have any 64 bit windows system, in fact the only windows that I
> have is a 32 bit winXP (which I don't often use). Even though I have
> never tested it on a 64 bit system, the libusb driver wizard (a tool
> delivered with libusb-win32 to generate a device driver to let the
> device communicate with libusb) does create a 64 bit driver.
hmm, I've never seen such libusb-win32 driver wizard, I'll look better :)

> I think it
> should work with a 32-bit binary on winXP-64 but I have never tested it.
> For the time being let's investigate the possibilities.
I suspect that on Win >= Vista 64 bit libusb-win32 doesn't currently
work. At least libusb-win32 forums are full of people asking help
about this and people lamenting that libusb-win32 ruined their usb
system (ouch!).

Anyway there are good news as I got in touch with libusb (1.0)
developers (see libusb.org) and some of them are working on a
WinUSB-based USB backend right in these days
(http://libusb.org/wiki/windows_backend). If their work succeed, then
there would finally be a cross-platform (win,mac,linux), up-to-date
(libusb-0.1 is no longer maintained!) USB library with lots of
features and a clean API :)

Would it be ok for you to upgrade to libusb-1.0 if and when the Win
port gets fixed?

Francesco

Re: [Usbpicprog-technical] win7 testing

[Frans S. <fra...@gm...>]

Hi Francesco,



> 2009/11/30 Frans Schreuder <fra...@gm...>:
> > I don't have any 64 bit windows system, in fact the only windows that I
> > have is a 32 bit winXP (which I don't often use). Even though I have
> > never tested it on a 64 bit system, the libusb driver wizard (a tool
> > delivered with libusb-win32 to generate a device driver to let the
> > device communicate with libusb) does create a 64 bit driver.
> hmm, I've never seen such libusb-win32 driver wizard, I'll look better :)

In my trunk there is even a 64 bit driver and a 64 bit version of libusb0_x64.dll
I have tested the 32 bit version on vista (installed it with compatibility XP mode)
and and it worked perfectly. So I am quite surprised that it doesn't work on 64 bit.
> 
> 
> > I think it
> > should work with a 32-bit binary on winXP-64 but I have never tested it.
> > For the time being let's investigate the possibilities.
> I suspect that on Win >= Vista 64 bit libusb-win32 doesn't currently
> work. At least libusb-win32 forums are full of people asking help
> about this and people lamenting that libusb-win32 ruined their usb
> system (ouch!).

Actually this happened with me as well the first time but just uninstalling libusb fixed the problem
When I then installed libusb in XP compatibility mode everything worked out perfectly.
> 
> Anyway there are good news as I got in touch with libusb (1.0)
> developers (see libusb.org) and some of them are working on a
> WinUSB-based USB backend right in these days
> (http://libusb.org/wiki/windows_backend). If their work succeed, then
> there would finally be a cross-platform (win,mac,linux), up-to-date
> (libusb-0.1 is no longer maintained!) USB library with lots of
> features and a clean API :)
> 
> Would it be ok for you to upgrade to libusb-1.0 if and when the Win
> port gets fixed?

I will definitely upgrade if it's there for all systems!

Re: [Usbpicprog-technical] win7 testing

[Francesco <f18...@ya...>]

Hi Frans,

2009/12/2 Frans Schreuder <fra...@gm...>:
>> Would it be ok for you to upgrade to libusb-1.0 if and when the Win
>> port gets fixed?
>
> I will definitely upgrade if it's there for all systems!
there has been a lot of work on the libusb-1.0 windows backend (see
http://libusb.org/wiki/windows_backend).
I'm confident that in few weeks it will be ready (it already works but
is not yet part of the official libusb repo).

To test it (specially on my win7 64bit system) I've ported upp_wx to
libusb-1.0. The port was quite straightforward (it mostly involved
cleaning up existing code and replacing the few "usb_*" calls with
"libusb_*" calls).
The port seems to work fine... I wonder if it would be ok for you to
create a branch ad-hoc for libusb-1.0 so that I can commit my modified
sources there (where they would remain until libusb-1.0 windows
backend is officially released).

Francesco

Re: [Usbpicprog-technical] win7 testing

[Frans S. <fra...@gm...>]

hi francesco,

I have been on a holiday since the last few weeks,
I will come back to you on wednesday.

Regards,

Frans

2010/1/26, Francesco <f18...@ya...>:
> Hi Frans,
>
> 2009/12/2 Frans Schreuder <fra...@gm...>:
>>> Would it be ok for you to upgrade to libusb-1.0 if and when the Win
>>> port gets fixed?
>>
>> I will definitely upgrade if it's there for all systems!
> there has been a lot of work on the libusb-1.0 windows backend (see
> http://libusb.org/wiki/windows_backend).
> I'm confident that in few weeks it will be ready (it already works but
> is not yet part of the official libusb repo).
>
> To test it (specially on my win7 64bit system) I've ported upp_wx to
> libusb-1.0. The port was quite straightforward (it mostly involved
> cleaning up existing code and replacing the few "usb_*" calls with
> "libusb_*" calls).
> The port seems to work fine... I wonder if it would be ok for you to
> create a branch ad-hoc for libusb-1.0 so that I can commit my modified
> sources there (where they would remain until libusb-1.0 windows
> backend is officially released).
>
> Francesco
>
> ------------------------------------------------------------------------------
> The Planet: dedicated and managed hosting, cloud storage, colocation
> Stay online with enterprise data centers and the best network in the
> business
> Choose flexible plans and management services without long-term contracts
> Personal 24x7 support from experience hosting pros just a phone call away.
> http://p.sf.net/sfu/theplanet-com
> _______________________________________________
> Usbpicprog-technical mailing list
> Usb...@li...
> https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical
>

Re: [Usbpicprog-technical] win7 testing

[Frans S. <fra...@gm...>]

Hi Francesco,

I have been trying the libusb1 branch on ubuntu. Apart from the fact
that libusb_strerror was missing in the linux version, it compiled fine.
It does also connect to the usbpicprog hardware, but in my case the
communication with the hardware is not stable at all. 
After connection it does read the firmware version and it can read a
couple of bytes from the PIC, but then it will give an error. I will try
further and let you know when I have more success...

Frans

-----Original Message-----
From: Frans Schreuder <fra...@gm...>
To: usb...@li...
Subject: Re: [Usbpicprog-technical] win7 testing
Date: Mon, 1 Feb 2010 12:34:41 +0300

hi francesco,

I have been on a holiday since the last few weeks,
I will come back to you on wednesday.

Regards,

Frans

2010/1/26, Francesco <f18...@ya...>:
> Hi Frans,
>
> 2009/12/2 Frans Schreuder <fra...@gm...>:
>>> Would it be ok for you to upgrade to libusb-1.0 if and when the Win
>>> port gets fixed?
>>
>> I will definitely upgrade if it's there for all systems!
> there has been a lot of work on the libusb-1.0 windows backend (see
> http://libusb.org/wiki/windows_backend).
> I'm confident that in few weeks it will be ready (it already works but
> is not yet part of the official libusb repo).
>
> To test it (specially on my win7 64bit system) I've ported upp_wx to
> libusb-1.0. The port was quite straightforward (it mostly involved
> cleaning up existing code and replacing the few "usb_*" calls with
> "libusb_*" calls).
> The port seems to work fine... I wonder if it would be ok for you to
> create a branch ad-hoc for libusb-1.0 so that I can commit my modified
> sources there (where they would remain until libusb-1.0 windows
> backend is officially released).
>
> Francesco
>
> ------------------------------------------------------------------------------
> The Planet: dedicated and managed hosting, cloud storage, colocation
> Stay online with enterprise data centers and the best network in the
> business
> Choose flexible plans and management services without long-term contracts
> Personal 24x7 support from experience hosting pros just a phone call away.
> http://p.sf.net/sfu/theplanet-com
> _______________________________________________
> Usbpicprog-technical mailing list
> Usb...@li...
> https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical
>

Re: [Usbpicprog-technical] win7 testing

[Frans S. <fra...@gm...>]

Hi Francesco,

The upp_wx-libusb1 seems to communicate stable with the bootloader in
ubuntu. Let me find out what the difference is...

Cheers,

Frans

-----Original Message-----
From: Frans Schreuder <fra...@gm...>
To: usb...@li...
Subject: Re: [Usbpicprog-technical] win7 testing
Date: Fri, 05 Feb 2010 21:11:18 +0100

Hi Francesco,

I have been trying the libusb1 branch on ubuntu. Apart from the fact
that libusb_strerror was missing in the linux version, it compiled fine.
It does also connect to the usbpicprog hardware, but in my case the
communication with the hardware is not stable at all. 
After connection it does read the firmware version and it can read a
couple of bytes from the PIC, but then it will give an error. I will try
further and let you know when I have more success...

Frans

-----Original Message-----
From: Frans Schreuder <fra...@gm...>
To: usb...@li...
Subject: Re: [Usbpicprog-technical] win7 testing
Date: Mon, 1 Feb 2010 12:34:41 +0300

hi francesco,

I have been on a holiday since the last few weeks,
I will come back to you on wednesday.

Regards,

Frans

2010/1/26, Francesco <f18...@ya...>:
> Hi Frans,
>
> 2009/12/2 Frans Schreuder <fra...@gm...>:
>>> Would it be ok for you to upgrade to libusb-1.0 if and when the Win
>>> port gets fixed?
>>
>> I will definitely upgrade if it's there for all systems!
> there has been a lot of work on the libusb-1.0 windows backend (see
> http://libusb.org/wiki/windows_backend).
> I'm confident that in few weeks it will be ready (it already works but
> is not yet part of the official libusb repo).
>
> To test it (specially on my win7 64bit system) I've ported upp_wx to
> libusb-1.0. The port was quite straightforward (it mostly involved
> cleaning up existing code and replacing the few "usb_*" calls with
> "libusb_*" calls).
> The port seems to work fine... I wonder if it would be ok for you to
> create a branch ad-hoc for libusb-1.0 so that I can commit my modified
> sources there (where they would remain until libusb-1.0 windows
> backend is officially released).
>
> Francesco
>
> ------------------------------------------------------------------------------
> The Planet: dedicated and managed hosting, cloud storage, colocation
> Stay online with enterprise data centers and the best network in the
> business
> Choose flexible plans and management services without long-term contracts
> Personal 24x7 support from experience hosting pros just a phone call away.
> http://p.sf.net/sfu/theplanet-com
> _______________________________________________
> Usbpicprog-technical mailing list
> Usb...@li...
> https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical
>

Re: [Usbpicprog-technical] win7 testing

[Francesco <f18...@ya...>]

Hi Frans!
    welcome back from holidays ;)

> I have been trying the libusb1 branch on ubuntu. Apart from the fact
> that libusb_strerror was missing in the linux version, it compiled fine.
well, I wrote libusb_strerror() and sent it as a patch to the libusb
guys and it has been queued for inclusion in the mainline together
with the windows-backend's patches. So your fix is right for now but
"soon" it should be an official libusb API function ;)

> It does also connect to the usbpicprog hardware, but in my case the
> communication with the hardware is not stable at all.
I know. It's true for me too :(

> After connection it does read the firmware version and it can read a
> couple of bytes from the PIC, but then it will give an error. I will try
> further and let you know when I have more success...
same here. It gives me lots of "Timeout errors".
However the errors seem to be triggered at random and so sometimes
I've been able to e.g. read the code memory of a PIC16 connected to
the programmer. Anyway in its current status it's not really usable,
unfortunately.

The only "positive" thing is that I see the same behaviour on both
Windows and Linux so that hopefully when we will fix it on linux it
probably will run fine also on Windows.

> The upp_wx-libusb1 seems to communicate stable with the bootloader in
> ubuntu. Let me find out what the difference is...
I tried to use wireshark as USB sniffer (see
http://biot.com/blog/usb-sniffing-on-linux) and I found out that when
the USB host controller sends "GET DESCRIPTOR request" packets the hw
will usually (maybe 100% of the times, I should check) reply with "GET
DESCRIPTOR response" packets which wireshark tags as [Malformed
Packet]s (they appear as 8 bytes packets containing only zeroes).

There's a developer on the libusb ML (Xiaofan Chen) which works with
PIC controllers and IIRC I read in one of his messages that the
Microchip USB stack is known to have many bugs. Are we using the
latest version of the Microchip USB stack?
Sorry for my ignorance but I still have to learn how to use the USB
subsystem of the PIC controllers (I'm planning a project USB-based but
it's still far from completion) and so it's difficult for me to check
the current *.c and *.h files in the uc_code folder.

Also note that the malformed packets I've seen are crafted by the the
upp hw you sent me (PCB ver 0.3) loaded with the very latest version
of the fw (788)...

Francesco

Re: [Usbpicprog-technical] win7 testing

[Francesco <f18...@ya...>]

Btw I just thought to compare the wireshark USB log for upp_wx trunk
(running with libusb-0.1) and the upp_wx branch (running with
libusb-1.0). The logs are very different. In the libusb-0.1 I never
saw any malformed packet created by upp programmer/bootloader.
In the libusb-1.0 branch I see tons of:

...
USB	GET DESCRIPTOR Request INTERFACE
GET DESCRIPTOR Response INTERFACE[Malformed Packet]
...

I'll see if I can get some help on this on the libusb mailing list...

Francesco


2010/2/6 Francesco <f18...@ya...>:
> Hi Frans!
>    welcome back from holidays ;)
>
>> I have been trying the libusb1 branch on ubuntu. Apart from the fact
>> that libusb_strerror was missing in the linux version, it compiled fine.
> well, I wrote libusb_strerror() and sent it as a patch to the libusb
> guys and it has been queued for inclusion in the mainline together
> with the windows-backend's patches. So your fix is right for now but
> "soon" it should be an official libusb API function ;)
>
>> It does also connect to the usbpicprog hardware, but in my case the
>> communication with the hardware is not stable at all.
> I know. It's true for me too :(
>
>> After connection it does read the firmware version and it can read a
>> couple of bytes from the PIC, but then it will give an error. I will try
>> further and let you know when I have more success...
> same here. It gives me lots of "Timeout errors".
> However the errors seem to be triggered at random and so sometimes
> I've been able to e.g. read the code memory of a PIC16 connected to
> the programmer. Anyway in its current status it's not really usable,
> unfortunately.
>
> The only "positive" thing is that I see the same behaviour on both
> Windows and Linux so that hopefully when we will fix it on linux it
> probably will run fine also on Windows.
>
>> The upp_wx-libusb1 seems to communicate stable with the bootloader in
>> ubuntu. Let me find out what the difference is...
> I tried to use wireshark as USB sniffer (see
> http://biot.com/blog/usb-sniffing-on-linux) and I found out that when
> the USB host controller sends "GET DESCRIPTOR request" packets the hw
> will usually (maybe 100% of the times, I should check) reply with "GET
> DESCRIPTOR response" packets which wireshark tags as [Malformed
> Packet]s (they appear as 8 bytes packets containing only zeroes).
>
> There's a developer on the libusb ML (Xiaofan Chen) which works with
> PIC controllers and IIRC I read in one of his messages that the
> Microchip USB stack is known to have many bugs. Are we using the
> latest version of the Microchip USB stack?
> Sorry for my ignorance but I still have to learn how to use the USB
> subsystem of the PIC controllers (I'm planning a project USB-based but
> it's still far from completion) and so it's difficult for me to check
> the current *.c and *.h files in the uc_code folder.
>
> Also note that the malformed packets I've seen are crafted by the the
> upp hw you sent me (PCB ver 0.3) loaded with the very latest version
> of the fw (788)...
>
> Francesco
>

Re: [Usbpicprog-technical] win7 testing

[Francesco <f18...@ya...>]

Hi Frans!

2010/2/6 Francesco <f18...@ya...>:
> In the libusb-1.0 branch I see tons of:
>
> ...
> USB     GET DESCRIPTOR Request INTERFACE
> GET DESCRIPTOR Response INTERFACE[Malformed Packet]
> ...
>
actually these continuous requests were the result of my (partially
erraneous) 0.1=>1.0 porting :/

basically the endpointMode() function was continuosly asking for the
INTERFACE descriptor to the hw before each read/write done by the
readString() and writeString() methods of Hardware class.
I've now fixed the code to never ask any interface/endpoint
descriptor. In fact checking the firmware I've seen that
GET_DESCRIPTOR packets for the INTERFACE descriptor are not handled.
This explains why wireshark always reported malformed packets as
replies.

Hopefully the branch should now be ready for everyday use...

Francesco

Re: [Usbpicprog-technical] win7 testing

[Frans S. <fra...@gm...>]

Hi Francesco,

Wow, it is working now perfectly!!!
Only for the bootloader I needed to make a small fix in usb
initialization, that one uses bulk in stead of interrupt:

	if(m_hwCurrent==HW_UPP)
	    m_modeReadEndpoint = m_modeWriteEndpoint =
LIBUSB_TRANSFER_TYPE_INTERRUPT;
	else 
		m_modeReadEndpoint = m_modeWriteEndpoint = LIBUSB_TRANSFER_TYPE_BULK;

But I think we can merge back now. (in fact there is nothing to merge
since nothing has changed in the trunk)

Cheers,

Frans

On Mon, 2010-02-08 at 00:26 +0100, Francesco wrote:

> Hi Frans!
> 
> 2010/2/6 Francesco <f18...@ya...>:
> > In the libusb-1.0 branch I see tons of:
> >
> > ...
> > USB     GET DESCRIPTOR Request INTERFACE
> > GET DESCRIPTOR Response INTERFACE[Malformed Packet]
> > ...
> >
> actually these continuous requests were the result of my (partially
> erraneous) 0.1=>1.0 porting :/
> 
> basically the endpointMode() function was continuosly asking for the
> INTERFACE descriptor to the hw before each read/write done by the
> readString() and writeString() methods of Hardware class.
> I've now fixed the code to never ask any interface/endpoint
> descriptor. In fact checking the firmware I've seen that
> GET_DESCRIPTOR packets for the INTERFACE descriptor are not handled.
> This explains why wireshark always reported malformed packets as
> replies.
> 
> Hopefully the branch should now be ready for everyday use...
> 
> Francesco
> 
> ------------------------------------------------------------------------------
> The Planet: dedicated and managed hosting, cloud storage, colocation
> Stay online with enterprise data centers and the best network in the business
> Choose flexible plans and management services without long-term contracts
> Personal 24x7 support from experience hosting pros just a phone call away.
> http://p.sf.net/sfu/theplanet-com
> _______________________________________________
> Usbpicprog-technical mailing list
> Usb...@li...
> https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical

Re: [Usbpicprog-technical] win7 testing

[Francesco <f18...@ya...>]

Hi Frans,

2010/2/8 Frans Schreuder <fra...@gm...>:
> Wow, it is working now perfectly!!!
> Only for the bootloader I needed to make a small fix in usb initialization,
> that one uses bulk in stead of interrupt:
>
> if(m_hwCurrent==HW_UPP)
>     m_modeReadEndpoint = m_modeWriteEndpoint =
> LIBUSB_TRANSFER_TYPE_INTERRUPT;
> else
> m_modeReadEndpoint = m_modeWriteEndpoint = LIBUSB_TRANSFER_TYPE_BULK;
good point ;)


> But I think we can merge back now. (in fact there is nothing to merge since
> nothing has changed in the trunk)
for me it's ok to merge. However I must say that I've been following
the libusb mailing list closely in the last two months and I'm not
sure when the new version of the libusb (with also the windows
backend) is going to be released.
It may take 2 weeks or perhaps 1 month. This means that if we merge
the upp_wx_libusb1 branch into the trunk users on Windows will have
some troubles compiling it (unless we upload the pthread-win32 and
libusb precompiled libs somewhere ;)).
Also I'm still figuring out how to install the drivers directly from
the Windows installer and also the build system (the one based on
bakefile) needs some tweaks for supporting the 64bit build mode...

Francesco

Re: [Usbpicprog-technical] win7 testing

[Frans S. <fra...@gm...>]

Hi Francesco,

I have merged anyway, because at least mingw32 and linux are building fine.
I have also included the libusb-1.dll and pthreadGC2.dll in the svn tree 
(32 bit).
I think it is good to include the 64 bit versions as well, but I don't 
have a way to build them.

I don't really know how to use these bakefile scripts etc... I have also 
never used the ms compiler, but I guess we will have to use it for the 
64-bit version.

Cheers,

Frans

Francesco wrote:
> Hi Frans,
>
> 2010/2/8 Frans Schreuder <fra...@gm...>:
>   
>> Wow, it is working now perfectly!!!
>> Only for the bootloader I needed to make a small fix in usb initialization,
>> that one uses bulk in stead of interrupt:
>>
>> if(m_hwCurrent==HW_UPP)
>>     m_modeReadEndpoint = m_modeWriteEndpoint =
>> LIBUSB_TRANSFER_TYPE_INTERRUPT;
>> else
>> m_modeReadEndpoint = m_modeWriteEndpoint = LIBUSB_TRANSFER_TYPE_BULK;
>>     
> good point ;)
>
>
>   
>> But I think we can merge back now. (in fact there is nothing to merge since
>> nothing has changed in the trunk)
>>     
> for me it's ok to merge. However I must say that I've been following
> the libusb mailing list closely in the last two months and I'm not
> sure when the new version of the libusb (with also the windows
> backend) is going to be released.
> It may take 2 weeks or perhaps 1 month. This means that if we merge
> the upp_wx_libusb1 branch into the trunk users on Windows will have
> some troubles compiling it (unless we upload the pthread-win32 and
> libusb precompiled libs somewhere ;)).
> Also I'm still figuring out how to install the drivers directly from
> the Windows installer and also the build system (the one based on
> bakefile) needs some tweaks for supporting the 64bit build mode...
>
> Francesco
>
> ------------------------------------------------------------------------------
> The Planet: dedicated and managed hosting, cloud storage, colocation
> Stay online with enterprise data centers and the best network in the business
> Choose flexible plans and management services without long-term contracts
> Personal 24x7 support from experience hosting pros just a phone call away.
> http://p.sf.net/sfu/theplanet-com
> _______________________________________________
> Usbpicprog-technical mailing list
> Usb...@li...
> https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical
>   

Re: [Usbpicprog-technical] win7 testing

[Francesco <f18...@ya...>]

Hi Frans,

2010/2/10 Frans Schreuder <fra...@gm...>:
> I have merged anyway, because at least mingw32 and linux are building fine.
I didn't see your merge when I commmitted r804. I'll now commit the
r804 to the trunk, then.

> I have also included the libusb-1.dll and pthreadGC2.dll in the svn tree
> (32 bit).
> I think it is good to include the 64 bit versions as well, but I don't
> have a way to build them.
no problem, I can commit them.
However I think that the current upp_wx directory layout is a bit
messy wrt to Windows-specific files.
The build files for mingw,borland,gcc,msvc compilers and msvc IDE
project files are in build\win.
The DevCpp project file is placed in the root folder (and I've seen it
contains absolute paths -- which is something which should be avoided;
the use of the WXWIN env variable on Windows is the preferred way to
build wx-based projects).
The windows drivers and installer are in windows_driver and
win_installer folders.
The precompiled win32 libusb dependencies are now in libusb1_win32.

I'd suggest to take the following actions:
1) create a single "win" folder (next to the 'osx' folder) with the
subdirectories "installer", "driver", "dependencies" and place into
the them the relative files.
2) move the DevCpp project from the root to the build\win\devcpp.dev file


> I don't really know how to use these bakefile scripts etc...
never mind, I'll take care of it. You just need to know that with a
single bakefile script I can create makefiles and project files for
lots of different compilers/IDEs which are common under Windows ;)

>I have also
> never used the ms compiler, but I guess we will have to use it for the
> 64-bit version.
this is true and unfortunately the MSVC++ 2008 Express edition (which
is free) doesn't support 64bit builds.
Only the Professional edition does. Luckily I have access to the
professional edition in my university and thus I can take care of the
64bit distribution.

Btw I have to say that MSVC is much better than e.g. mingw/cygwin when
working under windows: it's much faster and produces much smaller and
faster executables! I'd strongly reccomend to build the .exe files
packaged for distribution with MSVC instead of mingw!

Francesco

Re: [Usbpicprog-technical] win7 testing

[Francesco <f18...@ya...>]

2010/2/10 Francesco <f18...@ya...>:
> 1) create a single "win" folder (next to the 'osx' folder) with the
> subdirectories "installer", "driver", "dependencies" and place into
> the them the relative files.
I forgot to say that the "dependencies" folder (or even better "deps")
should then contain "amd64" and "x86" folders with the relative libusb
and libpthread binaries inside.

Another thing I forgot to say is that I'm now looking into the way to
install the driver, if the driver is not already installed, directly
from the upp_wx program (I'm planning to then submit the resulting
function as a patch to libusb itself) so that with NSIS/InnoSetup
(AFAIK InstallJammer doesn't allow the installation of 64bit apps!) it
will be possible to create an installer which runs on both 32bit and
64bit systems and is capable of correctly installing either a 32bit or
a 64bit binary (both can be packaged inside the same installer).
Then when the application runs for the first time it installs the driver.

This should be the best foolproof solution :)

Francesco

Re: [Usbpicprog-technical] win7 testing

[Frans S. <fra...@gm...>]

Francesco wrote:
> 2010/2/10 Francesco <f18...@ya...>:
>   
>> 1) create a single "win" folder (next to the 'osx' folder) with the
>> subdirectories "installer", "driver", "dependencies" and place into
>> the them the relative files.
>>     
> I forgot to say that the "dependencies" folder (or even better "deps")
> should then contain "amd64" and "x86" folders with the relative libusb
> and libpthread binaries inside.
>   
yes, that would be a good idea, but it shouldn't be only named amd64, 
but it should also contain something like "win" in its name
> Another thing I forgot to say is that I'm now looking into the way to
> install the driver, if the driver is not already installed, directly
> from the upp_wx program (I'm planning to then submit the resulting
> function as a patch to libusb itself) so that with NSIS/InnoSetup
> (AFAIK InstallJammer doesn't allow the installation of 64bit apps!) it
> will be possible to create an installer which runs on both 32bit and
> 64bit systems and is capable of correctly installing either a 32bit or
> a 64bit binary (both can be packaged inside the same installer).
> Then when the application runs for the first time it installs the driver.
>   
I have read some forums and blogs about combining 64 and 32 bit in one 
installer, e.g. this one:
http://stackoverflow.com/questions/1922259/how-to-implement-single-installer-for-32-64-platforms
and it doesn't seem to be very straightforward. It might save us from a 
lot of headaches to just create two separate installers. But of course 
installing the driver from the installer would be good.
> This should be the best foolproof solution :)
>   
I think that the average usbpicprog user does have some technical 
skills, they will be at least able to identify whether they have a 64 or 
32 bit os.
> Francesco
>
> ------------------------------------------------------------------------------
> SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
> Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
> http://p.sf.net/sfu/solaris-dev2dev
> _______________________________________________
> Usbpicprog-technical mailing list
> Usb...@li...
> https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical
>   

Re: [Usbpicprog-technical] win7 testing

[Francesco <f18...@ya...>]

Hi,

2010/2/11 Frans Schreuder <fra...@gm...>:
...
> yes, that would be a good idea,
ok, done. It looks much more polished now to me ;)

>but it shouldn't be only named amd64, but it
> should also contain something like "win" in its name
well, currently there are "amd64" and "x86" folders in all the
deps,installer,driver subfolders of "win". I think it's clear they're
related to win-only stuff being under "win".

> I have read some forums and blogs about combining 64 and 32 bit in one
> installer, e.g. this one:
> http://stackoverflow.com/questions/1922259/how-to-implement-single-installer-for-32-64-platforms
> and it doesn't seem to be very straightforward. It might save us from a lot
> of headaches to just create two separate installers.
I've played with the idea a bit but you're right. Two different
installers should work just fine after all given the type of users
we're targeting.

>But of course
> installing the driver from the installer would be good.
currently the driver installation is done by the dpinst utility which
Microsoft provides with the WDK and which is specifically designed for
driver installation.

> I think that the average usbpicprog user does have some technical skills,
> they will be at least able to identify whether they have a 64 or 32 bit os.
true...

Anyway I currently have managed to build the installers for 32bit and
64bit versions of upp_wx. They seem to work just fine (tested under
Win7 64bit and WinXP 32bit).
It would be important however to test them on as many systems as
possible. I could upload them to somewhere (e.g. in the webspace of
the SF usbpicprog project?) if someone else wants to test them on
other versions of Windows...

Francesco

Re: [Usbpicprog-technical] win7 testing

[Frans S. <fra...@gm...>]

Francesco wrote:
>
> done!
>
> Later I'll write an email to the upp mailing list to ask for testing of:
> http://usbpicprog.org/downloads/UsbPicProg-amd64-0.3.0.exe
> http://usbpicprog.org/downloads/UsbPicProg-x86-0.3.0.exe
>   
I've tried the x86 version on Win XP, but no success (it causes an 
exception with something like kernel32.dll and then libusb-1.0.dll)
Have you compiled it on Windows 7 amd64? or how did you compile it?
Also the location of the .mo files is not correct, for example the file 
nl.mo should be installed as
Program Files\Usbpicprog\po\nl\LC_MESSAGES\usbpicprog.mo
in stead of just po\nl.mo

> One thing I forgot to mention is that the amd64 version probably
> cannot install the (unsigned) drivers on 64bit Windows Vista and 7 if
> the users doesn't first activate the test mode with the command:
>    bcedit -set testsigning ON
> executed from a command prompt started in admin mode.
> Unfortunately AFAIK the only way to avoid the above step is to get a
> driver signature from MS but that costs money.
> Another solution could be to ask to the user (on 64bit window
> versions) if he wants to put his Windows in testsigning mode directly
> from the installer (I've found that the ppjoy programmer's is doing
> something like that:
> http://ppjoy.blogspot.com/2009/12/new-installer-feature.html)...
>   

sounds great, I think I will also have to run a virtual machine with 
win7 amd64
> Francesco
>   

Re: [Usbpicprog-technical] win7 testing

[Francesco <f18...@ya...>]

Hi,

2010/2/15 Frans Schreuder <fra...@gm...>:
> Francesco wrote:
>>
>> done!
>>
>> Later I'll write an email to the upp mailing list to ask for testing of:
>> http://usbpicprog.org/downloads/UsbPicProg-amd64-0.3.0.exe
>> http://usbpicprog.org/downloads/UsbPicProg-x86-0.3.0.exe
>>
> I've tried the x86 version on Win XP, but no success (it causes an
> exception with something like kernel32.dll and then libusb-1.0.dll)
very strange. Is it a WinXP without Service Packs installed?
Tomorrow (evening) I'll have a chance to test the installer on a
relatively vanilla WinXP installation (so far I've tested only on the
machine I use for programming and where I did miscellaneous driver
tests). I'll let you know what I get.

> Have you compiled it on Windows 7 amd64?
>or how did you compile it?
yes, I cross-compiled it for x86 from Win7 amd64 using MSVC++ 2008.
I used the "Static Release Multilib" configuration and built all
dependencies in release mode and with /MD option.

> Also the location of the .mo files is not correct, for example the file
> nl.mo should be installed as
> Program Files\Usbpicprog\po\nl\LC_MESSAGES\usbpicprog.mo
> in stead of just po\nl.mo
ouch, sorry.
I've fixed this now and uploaded corrected installers at:
http://usbpicprog.org/downloads/UsbPicProg-amd64-0.3.0.exe
http://usbpicprog.org/downloads/UsbPicProg-x86-0.3.0.exe

>> Another solution could be to ask to the user (on 64bit window
>> versions) if he wants to put his Windows in testsigning mode directly
>> from the installer (I've found that the ppjoy programmer's is doing
>> something like that:
>> http://ppjoy.blogspot.com/2009/12/new-installer-feature.html)...
>>
>
> sounds great,
ok, I will see to implement it in the weekend...

>I think I will also have to run a virtual machine with
> win7 amd64
note however that you cannot run a 64bit OS in a virtual machine
hosted on a 32bit OS (only the viceversa is possible)...

Francesco

Re: [Usbpicprog-technical] win7 testing

[Frans S. <fra...@gm...>]

Hi,

> > Francesco wrote:
> >>
> >> done!
> >>
> >> Later I'll write an email to the upp mailing list to ask for testing of:
> >> http://usbpicprog.org/downloads/UsbPicProg-amd64-0.3.0.exe
> >> http://usbpicprog.org/downloads/UsbPicProg-x86-0.3.0.exe
> >>
> > I've tried the x86 version on Win XP, but no success (it causes an
> > exception with something like kernel32.dll and then libusb-1.0.dll)
> very strange. Is it a WinXP without Service Packs installed?
> Tomorrow (evening) I'll have a chance to test the installer on a
> relatively vanilla WinXP installation (so far I've tested only on the
> machine I use for programming and where I did miscellaneous driver
> tests). I'll let you know what I get.

I have tried different XP machines (all SP3) and even wine. They all get
the same error.
Did you use the libusb-1.0.dll compiled by me? that one was built using
mingw, not MSVC++.

Backtrace:
=>0 0x7b866ffc InterlockedCompareExchange+0xc() in kernel32 (0x0032fc2c)
  1 0x00333358 in pthreadvc2 (+0x3358) (0x0032fc4c)
  2 0x10001e22 in libusb-1.0 (+0x1e22) (0x00845a78)
  3 0x00000000 (0x006020b4)
  4 0x004188d0 in usbpicprog (+0x188d0) (0x004ab910)


> 
> > Have you compiled it on Windows 7 amd64?
> >or how did you compile it?
> yes, I cross-compiled it for x86 from Win7 amd64 using MSVC++ 2008.
> I used the "Static Release Multilib" configuration and built all
> dependencies in release mode and with /MD option.
> 
> > Also the location of the .mo files is not correct, for example the file
> > nl.mo should be installed as
> > Program Files\Usbpicprog\po\nl\LC_MESSAGES\usbpicprog.mo
> > in stead of just po\nl.mo
> ouch, sorry.
> I've fixed this now and uploaded corrected installers at:
> http://usbpicprog.org/downloads/UsbPicProg-amd64-0.3.0.exe
> http://usbpicprog.org/downloads/UsbPicProg-x86-0.3.0.exe

I guess you didn't build the 0.3.0 version from tags, but the latest
trunk version. Shouldn't we call it 819 in stead of 0.3.0?

> 
> >> Another solution could be to ask to the user (on 64bit window
> >> versions) if he wants to put his Windows in testsigning mode directly
> >> from the installer (I've found that the ppjoy programmer's is doing
> >> something like that:
> >> http://ppjoy.blogspot.com/2009/12/new-installer-feature.html)...
> >>
> >
> > sounds great,
> ok, I will see to implement it in the weekend...
> 
> >I think I will also have to run a virtual machine with
> > win7 amd64
> note however that you cannot run a 64bit OS in a virtual machine
> hosted on a 32bit OS (only the viceversa is possible)...

Yes you can with virtualbox, as long as you have a 64 bit processor. But
anyway, I do run ubuntu amd64 so I won't have a problem.

Frans

Re: [Usbpicprog-technical] win7 testing

[Francesco <f18...@ya...>]

Hi,

2010/2/16 Frans Schreuder <fra...@gm...>:
>> I've tried the x86 version on Win XP, but no success (it causes an
>> exception with something like kernel32.dll and then libusb-1.0.dll)
> very strange. Is it a WinXP without Service Packs installed?
> Tomorrow (evening) I'll have a chance to test the installer on a
> relatively vanilla WinXP installation (so far I've tested only on the
> machine I use for programming and where I did miscellaneous driver
> tests). I'll let you know what I get.
>
> I have tried different XP machines (all SP3) and even wine. They all get the
> same error.
I don't know if it could be the source of problems but the machine
where I tested it is a WinXP SP2 pc.
Unfortunately today I didn't manage to test on a vanilla XP. I'll test
it tomorrow.

> Did you use the libusb-1.0.dll compiled by me? that one was built using mingw, not MSVC++.
no, I initially had some problems with the stuff which was in
libusb1_win32 folder so I recompiled everything (except pthread whose
precompiled versions were provided by Pete Batard on the win backend
homepage) with MSVC++, made sure to enable release mode and to have
the switch /MD used coherently everywhere....

> Backtrace:
> =>0 0x7b866ffc InterlockedCompareExchange+0xc() in kernel32 (0x0032fc2c)
>   1 0x00333358 in pthreadvc2 (+0x3358) (0x0032fc4c)
>   2 0x10001e22 in libusb-1.0 (+0x1e22) (0x00845a78)
>   3 0x00000000 (0x006020b4)
>   4 0x004188d0 in usbpicprog (+0x188d0) (0x004ab910)
>
it looks to be a problem in pthreadvc2 then.
Maybe I should build a debug version for now so that the EXE which
gets installed can be easily debugged with MSVC++.
Anyway probably in few days the pthread dependency willb e completely
removed from libusb, for the windows backend.

>> I've fixed this now and uploaded corrected installers at:
>> http://usbpicprog.org/downloads/UsbPicProg-amd64-0.3.0.exe
>> http://usbpicprog.org/downloads/UsbPicProg-x86-0.3.0.exe
>
> I guess you didn't build the 0.3.0 version from tags, but the latest trunk
> version. Shouldn't we call it 819 in stead of 0.3.0?
indeed. Will fix it.

>> note however that you cannot run a 64bit OS in a virtual machine
>> hosted on a 32bit OS (only the viceversa is possible)...
>
> Yes you can with virtualbox, as long as you have a 64 bit processor.
interesting, I didn't know...

> But
> anyway, I do run ubuntu amd64 so I won't have a problem.
if the problem persists I can setup a virtual machine, too (in the weekend)..

Francesco

Re: [Usbpicprog-technical] win7 testing

[Francesco <f18...@ya...>]

Hi,

2010/2/16 Francesco <f18...@ya...>:
> 2010/2/16 Frans Schreuder <fra...@gm...>:
>>> I've tried the x86 version on Win XP, but no success (it causes an
>>> exception with something like kernel32.dll and then libusb-1.0.dll)
>> very strange. Is it a WinXP without Service Packs installed?
>> Tomorrow (evening) I'll have a chance to test the installer on a
>> relatively vanilla WinXP installation (so far I've tested only on the
>> machine I use for programming and where I did miscellaneous driver
>> tests). I'll let you know what I get.
>>
>> I have tried different XP machines (all SP3) and even wine. They all get the
>> same error.
> I don't know if it could be the source of problems but the machine
> where I tested it is a WinXP SP2 pc.
> Unfortunately today I didn't manage to test on a vanilla XP. I'll test
> it tomorrow.
I've tested it on a WinXP SP3. The installation apparently was ok but
the installer asked me to reboot the machine.
After rebooting however I started upp_wx (with the upp hw not
connected) and I got an unhandled exception with a backtrace identical
to yours. Ouch.
Then I plugged in the upp hw. Windows didn't find the drivers (which
the installer should have installed in the driver store!) and asked me
for one.
I pointed it to C:\Program Files\UsbPicProg\driver and the
installation proceeded smoothly.
I restarted upp_wx and it worked.

This highlighted two problems:
1) libusb/libpthread seems buggy and if the driver is not installed it crashes;
2) dpinst seem not to have installed the driver correctly.

For #1 I think that it is a matter of re-compiling everything in debug
mode and run the app in MSVC and then make a proper bug report to
libusb/libpthread guys with a proper backtrace (with function names).
For #2 the problem is more on our shoulders.
I checked and this is the C:\windows\dpinst.log portion relative to
the installation of the upp driver:

INFO:   ****************************************
INFO:   02/16/2010 17:17:25
INFO:   Product Version 2.1.0.0.
INFO:   Version: 5.1.2600 Service Pack 3
INFO:   Platform ID: 2 (NT)
INFO:   Service Pack: 3.0
INFO:   Suite: 0x0100, Product Type: 1
INFO:   Architecture: X86.
INFO:   Interactive Windows Station
INFO:   Command Line: '"C:\Programmi\UsbPicProg\driver\dpinst.exe"'
INFO:   DPInst is a multi-lingual binary.
INFO:   ****************************************
INFO:   Current working directory: 'C:\Programmi\UsbPicProg\driver'
INFO:   Running on path 'C:\Programmi\UsbPicProg\driver'
INFO:   DPInst.xml does not list the current UI language.
INFO:   User UI Language is 0x410.
INFO:   Install option set: Suppressing Wizard but no OS popups.
INFO:   Install option set: Running in quiet mode. Suppressing Wizard
and OS popups.
INFO:   Install option set: legacy mode on.
INFO:   Install option set: Suppress Add or Remove Programs entries.
INFO:   Install option set: Install all driver packages or none.
INFO:   Found driver package: 'C:\Programmi\UsbPicProg\driver\bootloader.inf'.
INFO:   Found driver package: 'C:\Programmi\UsbPicProg\driver\upp.inf'.
INFO:   Preinstalling 'c:\programmi\usbpicprog\driver\bootloader.inf' ...
INFO:   ENTER:  DriverPackagePreinstallW
WARNING:Driver Package 'bootloader.inf' references Catalog file
'c:\programmi\usbpicprog\driver\libusb_device.cat' that cannot be
found.
INFO:   Copied 'bootloader.inf' to driver store...
INFO:   Commiting queue...
INFO:   Copied file:
'c:\programmi\usbpicprog\driver\x86\WinUSBCoInstaller2.dll' ->
'C:\WINDOWS\system32\DRVSTORE\bootloader_F389A405038599F0F7494EC02C7E9AE68D9598EF\x86\WinUSBCoInstaller2.dll'.
INFO:   Copied file:
'c:\programmi\usbpicprog\driver\x86\WdfCoInstaller01009.dll' ->
'C:\WINDOWS\system32\DRVSTORE\bootloader_F389A405038599F0F7494EC02C7E9AE68D9598EF\x86\WdfCoInstaller01009.dll'.
INFO:   Removed driver package from store.
INFO:   RETURN: DriverPackagePreinstallW  (0xE000022F)
INFO:   Returning with code 0x80020000
INFO:   02/16/2010 17:17:28

the warning about the cat shouldn't be a problem (it's a real problem
only if <legacyMode> is not used in the dpinst.xml file).
The problem is that the return code indicates (see
http://msdn.microsoft.com/en-us/library/ms791066.aspx) that
1) a driver package could not be installed
2) the number of driver packages that could not be installed is 2
Now, I realized that there is indeed a bug in the parsing of the
dpinst return code. I should have fixed it now.
However I still don't understand why dpinst failed the installation
and the log above doesn't help (looking at it, except for the return
code, everything seems ok). I need to do some search about this.

Francesco