Accessing file system from with a UMDF

I am developing a UMDF USB driver to drive a company product.
The current version of the driver uses a two-stage installation to:
(1) Download the firmware using a 3rd part driver (Cypress CyUSB).
This causes the device to renumerate and appear as a different VID/PID combo.
(2) Install the main UMDF driver for the new VID/PID

What I would like to do is to have the UMDF driver handle both stages.
I can get the required file name into the driver via the INF file and retrieve it via the
driver’s PropertyStore.

Q1: Am I allowed to use CreateFile to access the file and load the firmware into driver
memory so that I can send it to the device?
Q2: Are there any caveats I should be aware of, and any sample code to demonstrate how
to do this?

Thanks in advance.
Peter Young

Definitely not my area (UMDF), but I believe that UMDF runs in a particular
account, so you might not be able to access files quite so directly.

mm

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@vgieurope.com
Sent: Tuesday, February 01, 2011 6:33 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Accessing file system from with a UMDF

I am developing a UMDF USB driver to drive a company product.
The current version of the driver uses a two-stage installation to:
(1) Download the firmware using a 3rd part driver (Cypress CyUSB).
This causes the device to renumerate and appear as a different VID/PID
combo.
(2) Install the main UMDF driver for the new VID/PID

What I would like to do is to have the UMDF driver handle both stages.
I can get the required file name into the driver via the INF file and
retrieve it via the
driver’s PropertyStore.

Q1: Am I allowed to use CreateFile to access the file and load the firmware
into driver
memory so that I can send it to the device?
Q2: Are there any caveats I should be aware of, and any sample code to
demonstrate how
to do this?

Thanks in advance.
Peter Young


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

UMDF driver runs under LocalService account. It can access the file if it is accessible by this account. Is it possible for you to set the corresponding permissions on the file?

Praveen

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Martin O’Brien
Sent: Tuesday, February 01, 2011 3:35 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Accessing file system from with a UMDF

Definitely not my area (UMDF), but I believe that UMDF runs in a particular account, so you might not be able to access files quite so directly.

mm

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@vgieurope.com
Sent: Tuesday, February 01, 2011 6:33 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Accessing file system from with a UMDF

I am developing a UMDF USB driver to drive a company product.
The current version of the driver uses a two-stage installation to:
(1) Download the firmware using a 3rd part driver (Cypress CyUSB).
This causes the device to renumerate and appear as a different VID/PID combo.
(2) Install the main UMDF driver for the new VID/PID

What I would like to do is to have the UMDF driver handle both stages.
I can get the required file name into the driver via the INF file and retrieve it via the driver’s PropertyStore.

Q1: Am I allowed to use CreateFile to access the file and load the firmware into driver
memory so that I can send it to the device?
Q2: Are there any caveats I should be aware of, and any sample code to demonstrate how
to do this?

Thanks in advance.
Peter Young


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


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

xxxxx@vgieurope.com wrote:

I am developing a UMDF USB driver to drive a company product.
The current version of the driver uses a two-stage installation to:
(1) Download the firmware using a 3rd part driver (Cypress CyUSB).
This causes the device to renumerate and appear as a different VID/PID combo.
(2) Install the main UMDF driver for the new VID/PID

What I would like to do is to have the UMDF driver handle both stages.
I can get the required file name into the driver via the INF file and retrieve it via the
driver’s PropertyStore.

Q1: Am I allowed to use CreateFile to access the file and load the firmware into driver
memory so that I can send it to the device?
Q2: Are there any caveats I should be aware of, and any sample code to demonstrate how
to do this?

Do you really need a custom driver? You can do all of this using WinUSB
directly from your application. Loading FX2 firmware is a very simple
series of vendor commands.


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

Tim,

Yes I do need a custom driver as it can driver several ‘flavours’ of the companies interface hardware and I need to be able to program it based on the interface flavour I see and the device type it is going to be connected to.

I have now resolved the issue and can find and load the firmware file having retrieved the file path from the driver instance’s PropertyStore.

My problem now is going through the process of downloading the firmware and renumerating the device to get the functioning version of the interface to appear.

I have found some sample code which seems to indicate that to do this for a Cypress FX2-LP chip I need to do the following:

  1. Set the Reset bit High to put the CPU into RESET
  2. Load the Vendor firmware (Vend_Ax) loading code into external memory (A3)
  3. Set the Reset bit Low to take the CPU out of RESET
  4. Load the Vendor firmware (Vend_Ax) loading code into internal memory (A0)
  5. Load the required firmware (mine) into external memory (A3)
  6. Set the Reset bit High to put the CPU into RESET
  7. Load the required firmware (mine) into external memory (A0)
  8. Set the Reset bit Low to take the CPU out of RESET
  9. Set the DISCON and RENUM bits to tell the interface to renumerate.

Is this the correct sequence?
If not what have I missed out or what do I not need to do?

My main problem at the moment is that the first write to the control endpoint to transfer the Vend_Ax times out, but I have no idea why. Any ideas?

xxxxx@vgieurope.com wrote:


My problem now is going through the process of downloading the firmware and renumerating the device to get the functioning version of the interface to appear.

I have found some sample code which seems to indicate that to do this for a Cypress FX2-LP chip I need to do the following:

  1. Set the Reset bit High to put the CPU into RESET
  2. Load the Vendor firmware (Vend_Ax) loading code into external memory (A3)
  3. Set the Reset bit Low to take the CPU out of RESET
  4. Load the Vendor firmware (Vend_Ax) loading code into internal memory (A0)
  5. Load the required firmware (mine) into external memory (A3)
  6. Set the Reset bit High to put the CPU into RESET
  7. Load the required firmware (mine) into external memory (A0)
  8. Set the Reset bit Low to take the CPU out of RESET
  9. Set the DISCON and RENUM bits to tell the interface to renumerate.

Is this the correct sequence?
If not what have I missed out or what do I not need to do?

The vend_ax firmware is very small, and fits entirely in the internal
memory. Unless you are extraordinarily wordy, your firmware is probably
ALSO very small, and probably ALSO fits in the internal memory. I’ve
done a lot of FX2 projects, and I’ve never had to load anything into the
external memory.

More importantly, however, the vend_ax firmware is only necessary if you
need to burn the firmware into EEPROM. If all you are doing is loading
transient firmware into the onboard RAM, then all you need are steps 1,
7, 8, and 9. The firmware load commands (A0 and A3) are built-in to the
chip.


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

Tim,

Thanks for that - I have removed the unrequired code and now have the following:

  1. Set the Reset bit High to put the CPU into RESET
  2. Load the required firmware (mine) into external memory (A0)
  3. Set the Reset bit Low to take the CPU out of RESET
  4. Set the DISCON and RENUM bits to tell the interface to renumerate.

I am reading the firmware from an Intel-Hex format file and sending the records down to the device.

Do you have any sample code for the download via the UMDF Control endpoint as am still not getting the disconnect and reconnect and am not sure what I am missing.

xxxxx@vgieurope.com wrote:

Thanks for that - I have removed the unrequired code and now have the following:

  1. Set the Reset bit High to put the CPU into RESET
  2. Load the required firmware (mine) into external memory (A0)

Well, A0 is the INTERNAL memory load, which is what you want.

  1. Set the Reset bit Low to take the CPU out of RESET
  2. Set the DISCON and RENUM bits to tell the interface to renumerate.

I am reading the firmware from an Intel-Hex format file and sending the records down to the device.

Do you have any sample code for the download via the UMDF Control endpoint as am still not getting the disconnect and reconnect and am not sure what I am missing.

I’ve done this sequence in a lot of environments (including Python code
talking to libusb), but not for UMDF. Yet.

You’re doing your requests 64 bytes at a time, incrementing the address
(wValue) by 64 each time, yes? You’re advancing the buffer pointer by
64 each time? Something like:

WINUSB_SETUP_PACKET wsp;
ZeroMemory( &wsp, sizeof(wsp) );
wsp.RequestType = 0x40; // vendor request to device
wsp.Request = 0xA0; // ANCHOR_LOAD_INTERNAL

#define CHUNK 64

for(
unsigned short address = 0;
address < totalLength;
address += CHUNK, buffer += CHUNK
)
{
wsp.Value = address;
wsp.Length = min( CHUNK, totalLength-address );
WinUsb_ControlTransfer( handle, &wsp, buffer, wsp.Length, NULL, NULL );
}

Then, for Reset, you’re using the exact same command (0x40 and 0xA0) to
the address 0xE600?


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

> > Do you have any sample code for the download via the UMDF Control endpoint as am still not getting the disconnect and reconnect and am not sure what I am missing.

UMDF Fx2 sample demonstrates this as well. Please look at:

<wdk_dir>\src\usb\osrusbfx2\umdf\fx2_driver\final\Device.cpp

SendControlTransferSynchronously shows synchronous sending of control transfer. Of course, you can do async as well.

Praveen</wdk_dir>