USB Firmware Upgrade

NTDEV
1

All,

We have a USB device that supports firmware upgrade. It does it in the
typical way: on command the device disconnects and then reconnects in boot
loader mode. In this particular device, the descriptors reported by the boot
loader are identical to those reported by the device’s application firmware.
We’re currently testing on WinXP, SP3, 32-bit and the driver is written
using WDM (it’s been around for a while).

The problem that we’re seeing is as follows: When we enter boot loader mode,
we see the surprise removal for the running device and then we see arrival
(AddDevice, Start, etc) for the boot loader. However, we never see the
device removal for the running device. Additionally, we are seeing the exact
same pathname reported (via Device Arrival Notification at the application
level) by the boot loader as that used by the device’s application.

I’m wondering if this problem is caused because identical descriptors are
reported for both the running device application and the boot loader. I know
that typically, the boot loader reports a completely different set of
descriptors - but I’m not sure if that is required or not.

Does anyone know if different descriptors (at least a different serial
number) are required to be reported by the boot loader? Does anyone have
experience working with boot loaders that report identical descriptors as
the running application?

TIA!

2

The running device is stuck in the surprise removal state (and not removed) because your app has not closed its handle to the device. Register for file handle notifications and close the handle when notified. Usually the boot loader mode of the device has a different hardware ID identity, not just a diff serial number. You want a diff identity so that you can install a different driver, or at the very least, install the same driver with a different INF section so that you can apply different properties/reg values to the devnode.

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of JimmyJames
Sent: Tuesday, June 19, 2012 10:48 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] USB Firmware Upgrade

All,

We have a USB device that supports firmware upgrade. It does it in the typical way: on command the device disconnects and then reconnects in boot loader mode. In this particular device, the descriptors reported by the boot loader are identical to those reported by the device’s application firmware.
We’re currently testing on WinXP, SP3, 32-bit and the driver is written using WDM (it’s been around for a while).

The problem that we’re seeing is as follows: When we enter boot loader mode, we see the surprise removal for the running device and then we see arrival (AddDevice, Start, etc) for the boot loader. However, we never see the device removal for the running device. Additionally, we are seeing the exact same pathname reported (via Device Arrival Notification at the application
level) by the boot loader as that used by the device’s application.

I’m wondering if this problem is caused because identical descriptors are reported for both the running device application and the boot loader. I know that typically, the boot loader reports a completely different set of descriptors - but I’m not sure if that is required or not.

Does anyone know if different descriptors (at least a different serial
number) are required to be reported by the boot loader? Does anyone have experience working with boot loaders that report identical descriptors as the running application?

TIA!

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

3

JimmyJames wrote:

The problem that we’re seeing is as follows: When we enter boot loader mode,
we see the surprise removal for the running device and then we see arrival
(AddDevice, Start, etc) for the boot loader. However, we never see the
device removal for the running device.

I’m not sure what that means. Is this WDM? Which IRPs do you see, and
which do you expect?

Additionally, we are seeing the exact
same pathname reported (via Device Arrival Notification at the application
level) by the boot loader as that used by the device’s application.

That is normal. The path is based on your location and your VID, PID,
and serial number. Those haven’t changed. Does your application still
have an open handle? The driver stack for the old device cannot be
stopped and unloaded until all open handles are closed.

Does anyone know if different descriptors (at least a different serial
number) are required to be reported by the boot loader? Does anyone have
experience working with boot loaders that report identical descriptors as
the running application?

The PnP behavior doesn’t changed based on the descriptors. How will
your application know that the device is now in “firmware loading”
mode? Does it have to assume that because it made the request? What
happens if you get interrupted in the middle, or if the device gets
unplugged and replugged, or the application crashes? It seems pretty
delicate.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

4

Device Notification *is* implemented and under normal surprise removal
scenarios it all works just fine. It’s only in this firmware download
situation where the removal notification is never being sent to the
application.

“Doron Holan” wrote in message
news:xxxxx@ntdev…
The running device is stuck in the surprise removal state (and not removed)
because your app has not closed its handle to the device. Register for file
handle notifications and close the handle when notified. Usually the boot
loader mode of the device has a different hardware ID identity, not just a
diff serial number. You want a diff identity so that you can install a
different driver, or at the very least, install the same driver with a
different INF section so that you can apply different properties/reg values
to the devnode.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of JimmyJames
Sent: Tuesday, June 19, 2012 10:48 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] USB Firmware Upgrade

All,

We have a USB device that supports firmware upgrade. It does it in the
typical way: on command the device disconnects and then reconnects in boot
loader mode. In this particular device, the descriptors reported by the boot
loader are identical to those reported by the device’s application firmware.
We’re currently testing on WinXP, SP3, 32-bit and the driver is written
using WDM (it’s been around for a while).

The problem that we’re seeing is as follows: When we enter boot loader mode,
we see the surprise removal for the running device and then we see arrival
(AddDevice, Start, etc) for the boot loader. However, we never see the
device removal for the running device. Additionally, we are seeing the exact
same pathname reported (via Device Arrival Notification at the application
level) by the boot loader as that used by the device’s application.

I’m wondering if this problem is caused because identical descriptors are
reported for both the running device application and the boot loader. I know
that typically, the boot loader reports a completely different set of
descriptors - but I’m not sure if that is required or not.

Does anyone know if different descriptors (at least a different serial
number) are required to be reported by the boot loader? Does anyone have
experience working with boot loaders that report identical descriptors as
the running application?

TIA!

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

5

I don’t know what you are talking abou.t. I realize that PnP behavior
doesn’t normal changed based on the descriptors however: in this case the
driver receives a IRP_MN_SURPRISE_REMOVAL and then the AddDevice for the
bootloader - even before the first device has been removed - thus an
identical device (that has just been pulled off the bus) is now immediately
present again. It would seem to me that the PnP manager is getting confussed
and never generating the appropriate remove sequence.

“Tim Roberts” wrote in message news:xxxxx@ntdev…
> JimmyJames wrote:
>> The problem that we’re seeing is as follows: When we enter boot loader
>> mode,
>> we see the surprise removal for the running device and then we see
>> arrival
>> (AddDevice, Start, etc) for the boot loader. However, we never see the
>> device removal for the running device.
>
> I’m not sure what that means. Is this WDM? Which IRPs do you see, and
> which do you expect?
>
>
>> Additionally, we are seeing the exact
>> same pathname reported (via Device Arrival Notification at the
>> application
>> level) by the boot loader as that used by the device’s application.
>
> That is normal. The path is based on your location and your VID, PID,
> and serial number. Those haven’t changed. Does your application still
> have an open handle? The driver stack for the old device cannot be
> stopped and unloaded until all open handles are closed.
>
>
>> Does anyone know if different descriptors (at least a different serial
>> number) are required to be reported by the boot loader? Does anyone have
>> experience working with boot loaders that report identical descriptors as
>> the running application?
>
> The PnP behavior doesn’t changed based on the descriptors. How will
> your application know that the device is now in “firmware loading”
> mode? Does it have to assume that because it made the request? What
> happens if you get interrupted in the middle, or if the device gets
> unplugged and replugged, or the application crashes? It seems pretty
> delicate.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>

6

JimmyJames wrote:

I don’t know what you are talking abou.t. I realize that PnP behavior
doesn’t normal changed based on the descriptors however: in this case the
driver receives a IRP_MN_SURPRISE_REMOVAL and then the AddDevice for the
bootloader - even before the first device has been removed - thus an
identical device (that has just been pulled off the bus) is now immediately
present again. It would seem to me that the PnP manager is getting confussed
and never generating the appropriate remove sequence.

I’ve become a bit confused. Are you saying there are PnP messages
you’re not seeing in the driver, or are you simply saying the
WM_DEVICECHANGE message is not getting sent to your application? Or both?

It’s certainly possible for the new device to come up before the old one
has gone away. They don’t share any resources, so there should be no
conflicts. As Doron pointed out, the old device can’t be finally
removed until the last user-mode handle is closed. If you’re using
device interfaces, the next run through the SetupDi APIs should produce
a link to the new device.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

7

I have seen one point of confusion before with respect to handling remove. Are you registering for notifications on the file you opened or relying on a notification on the interface itself, interface removal, to close the handle?

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Tuesday, June 19, 2012 3:39 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] USB Firmware Upgrade

JimmyJames wrote:

I don’t know what you are talking abou.t. I realize that PnP behavior
doesn’t normal changed based on the descriptors however: in this case
the driver receives a IRP_MN_SURPRISE_REMOVAL and then the AddDevice
for the bootloader - even before the first device has been removed -
thus an identical device (that has just been pulled off the bus) is
now immediately present again. It would seem to me that the PnP
manager is getting confussed and never generating the appropriate remove sequence.

I’ve become a bit confused. Are you saying there are PnP messages you’re not seeing in the driver, or are you simply saying the WM_DEVICECHANGE message is not getting sent to your application? Or both?

It’s certainly possible for the new device to come up before the old one has gone away. They don’t share any resources, so there should be no conflicts. As Doron pointed out, the old device can’t be finally removed until the last user-mode handle is closed. If you’re using device interfaces, the next run through the SetupDi APIs should produce a link to the new device.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

8

We are registering for notification on the device handle that is being
opened via CreateFile. Furthermore, we’re using the path name returned by
SetupDi. in the call to CreateFile. Under normal surprise removal scenarios
(i.e.: someone pulls the plug) we see the WM_DEVICECHANGE notification
message with the dbch_devicetype == DBT_DEVTYPE_HANDLE.
Thx.

“Doron Holan” wrote in message
news:xxxxx@ntdev…
I have seen one point of confusion before with respect to handling remove.
Are you registering for notifications on the file you opened or relying on a
notification on the interface itself, interface removal, to close the
handle?

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Tuesday, June 19, 2012 3:39 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] USB Firmware Upgrade

JimmyJames wrote:
> I don’t know what you are talking abou.t. I realize that PnP behavior
> doesn’t normal changed based on the descriptors however: in this case
> the driver receives a IRP_MN_SURPRISE_REMOVAL and then the AddDevice
> for the bootloader - even before the first device has been removed -
> thus an identical device (that has just been pulled off the bus) is
> now immediately present again. It would seem to me that the PnP
> manager is getting confussed and never generating the appropriate remove
> sequence.

I’ve become a bit confused. Are you saying there are PnP messages you’re
not seeing in the driver, or are you simply saying the WM_DEVICECHANGE
message is not getting sent to your application? Or both?

It’s certainly possible for the new device to come up before the old one has
gone away. They don’t share any resources, so there should be no conflicts.
As Doron pointed out, the old device can’t be finally removed until the last
user-mode handle is closed. If you’re using device interfaces, the next run
through the SetupDi APIs should produce a link to the new device.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

9

I’ve inserted comments in-line below.
Thx.

“Tim Roberts” wrote in message news:xxxxx@ntdev…
> JimmyJames wrote:
>> I don’t know what you are talking abou.t. I realize that PnP behavior
>> doesn’t normal changed based on the descriptors however: in this case the
>> driver receives a IRP_MN_SURPRISE_REMOVAL and then the AddDevice for the
>> bootloader - even before the first device has been removed - thus an
>> identical device (that has just been pulled off the bus) is now
>> immediately
>> present again. It would seem to me that the PnP manager is getting
>> confussed
>> and never generating the appropriate remove sequence.
>
> I’ve become a bit confused. Are you saying there are PnP messages
> you’re not seeing in the driver, or are you simply saying the
> WM_DEVICECHANGE message is not getting sent to your application? Or both?

Both. We don’t get the WM_DEVICECHANGE in response to the surprise removal.
Because the application does not receive the notification, it never closes
the device handle - thus the driver never sees the IRP_MN_REMOVAL. (it does
however get the IRP_MN_SURPRISE_REMOVAL).

>
> It’s certainly possible for the new device to come up before the old one
> has gone away. They don’t share any resources, so there should be no
> conflicts. As Doron pointed out, the old device can’t be finally
> removed until the last user-mode handle is closed. If you’re using
> device interfaces, the next run through the SetupDi APIs should produce
> a link to the new device.

Since it is the exact same device and since the old device was never removed
it seems possible that it is using the same resources. The other thing is
that the pathname reported in the dbcc_name member of
DEV_BROADCAST_DEVICEINTERFACE during arrival is exactly the same as the
device just (surprised) removed. Since the slot/bus seg are encode in the
dbcc_name and since they are the same - then certainly at lease some of the
same resources are being shared.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>

10

Does this repro if the fw loader instance comes up with a diff vid/pid ?

d

debt from my phone

From: JimmyJames
Sent: 6/19/2012 5:21 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] USB Firmware Upgrade

I’ve inserted comments in-line below.
Thx.

“Tim Roberts” wrote in message news:xxxxx@ntdev…
> JimmyJames wrote:
>> I don’t know what you are talking abou.t. I realize that PnP behavior
>> doesn’t normal changed based on the descriptors however: in this case the
>> driver receives a IRP_MN_SURPRISE_REMOVAL and then the AddDevice for the
>> bootloader - even before the first device has been removed - thus an
>> identical device (that has just been pulled off the bus) is now
>> immediately
>> present again. It would seem to me that the PnP manager is getting
>> confussed
>> and never generating the appropriate remove sequence.
>
> I’ve become a bit confused. Are you saying there are PnP messages
> you’re not seeing in the driver, or are you simply saying the
> WM_DEVICECHANGE message is not getting sent to your application? Or both?

Both. We don’t get the WM_DEVICECHANGE in response to the surprise removal.
Because the application does not receive the notification, it never closes
the device handle - thus the driver never sees the IRP_MN_REMOVAL. (it does
however get the IRP_MN_SURPRISE_REMOVAL).

>
> It’s certainly possible for the new device to come up before the old one
> has gone away. They don’t share any resources, so there should be no
> conflicts. As Doron pointed out, the old device can’t be finally
> removed until the last user-mode handle is closed. If you’re using
> device interfaces, the next run through the SetupDi APIs should produce
> a link to the new device.

Since it is the exact same device and since the old device was never removed
it seems possible that it is using the same resources. The other thing is
that the pathname reported in the dbcc_name member of
DEV_BROADCAST_DEVICEINTERFACE during arrival is exactly the same as the
device just (surprised) removed. Since the slot/bus seg are encode in the
dbcc_name and since they are the same - then certainly at lease some of the
same resources are being shared.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

11

From my experience I’ve seen two scenarios working:

  1. Using the same device class and the same Vid/Pid, the FWupdate application sends a vendor specific command to the device nad the device receives in the next transmission the NEW firmware binary. This binary is written into the free space in EEPROM and checked by the running FW. If all is OK the device finishes with a “plug out and plug in” and comes back with the new FW running (it marks the old FW in the EEPROM as “free” space for the next potential update).

  2. Use a different device class (e.g. DFU) and a different Vid/Pid. Then you will typically need a second driver for this purpose. The device gets a specific comand to switch it into the DFU-mode (bootloader mode). It gets enumerated for the second driver and now you can do the FWupdate in he same way like above or in a different way but at the end you have to make sure the device comes back with the first interface (Vid/Pid).

If you inevitably need the “bootloader mode” before the firmware update starts, then I’d say the second scenario is the better choice.

As far I understand you the first scenario is the one you are implementing. If that is true you don’t need to disconnect the device and put it into the bootloader mode. The device disconnects itself at the end of the FW-update and returns updated. If it fails, the old FW is still active.

Hope this helps.
Hans.

12

We’re trying that now to see what happens - I’ll keep you posted.
“Doron Holan” wrote in message news:xxxxx@ntdev…
Does this repro if the fw loader instance comes up with a diff vid/pid ?

d

debt from my phone

------------------------------------------------------------------------------
From: JimmyJames
Sent: 6/19/2012 5:21 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] USB Firmware Upgrade

I’ve inserted comments in-line below.
Thx.

“Tim Roberts” wrote in message news:xxxxx@ntdev…
> JimmyJames wrote:
>> I don’t know what you are talking abou.t. I realize that PnP behavior
>> doesn’t normal changed based on the descriptors however: in this case the
>> driver receives a IRP_MN_SURPRISE_REMOVAL and then the AddDevice for the
>> bootloader - even before the first device has been removed - thus an
>> identical device (that has just been pulled off the bus) is now
>> immediately
>> present again. It would seem to me that the PnP manager is getting
>> confussed
>> and never generating the appropriate remove sequence.
>
> I’ve become a bit confused. Are you saying there are PnP messages
> you’re not seeing in the driver, or are you simply saying the
> WM_DEVICECHANGE message is not getting sent to your application? Or both?

Both. We don’t get the WM_DEVICECHANGE in response to the surprise removal.
Because the application does not receive the notification, it never closes
the device handle - thus the driver never sees the IRP_MN_REMOVAL. (it does
however get the IRP_MN_SURPRISE_REMOVAL).

>
> It’s certainly possible for the new device to come up before the old one
> has gone away. They don’t share any resources, so there should be no
> conflicts. As Doron pointed out, the old device can’t be finally
> removed until the last user-mode handle is closed. If you’re using
> device interfaces, the next run through the SetupDi APIs should produce
> a link to the new device.

Since it is the exact same device and since the old device was never removed
it seems possible that it is using the same resources. The other thing is
that the pathname reported in the dbcc_name member of
DEV_BROADCAST_DEVICEINTERFACE during arrival is exactly the same as the
device just (surprised) removed. Since the slot/bus seg are encode in the
dbcc_name and since they are the same - then certainly at lease some of the
same resources are being shared.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

13

Methods described by Han are the available options to you.

If you need to implement fw upgrade using same driver, use custom defined message to transfer and write image to ROM (need support from FW).

if you want to invoke DFU from driver you can do the following.
put a flag on the device which is checked by device each time it boots, and reports appropriate USB descriptors (DFU or normal).
In the driver, set that flag and reset device.
This should make fw to enter the DFU mode and report different PID.