Wednesday, 30 September 2009

Negating the need to run MakeImage when developing device drivers on WinCE

Debugging of drivers on Windows CE can be painful when downloading large images, NK.bin's of 10-30mb are typical and having to download the whole of this just for a driver modification can mean long times between compilation and testing. Here are my three methods for quicker development without having to push the full nk.bin down each time.

The firstly two methods have pretty much the same outcome but from a different approach:

1 - Remove the driver from the platform.bib file.

This means that the driver isn't embedded in the OS image (nk.bin), then run this image when on KITL enabled (the debug transport typically used to connect the target device to the development PC). This will result in the DLL being pulled from the desktop release directory over the KITL transport and being ran as if it were in the image.

2 - Tell Platform builder to force loading of modules over KITL

In Platform Builder go to

Target -> Release Directory Modules

Then include the DLL's that you want to force loading over the KITL connection, this tells the OS on start-up to ignore any DLLs included in the image. The benefit of this is that you don't even have to build the NK.BIN again.

3 - Load the drivers at runtime using ActiveDevice

This method is handy if you don't have a KITL connection, here we populate the registry with the driver entries, but instead of putting them under HKLM\Drivers\Builtin\ put the registry entry under HKLM\Drivers\Test\ to ensure that the system doesn't load the driver on start-up.

Then create a simple application that will tell device.exe to load the driver when you run it:

HANDLE device = ActivateDevice(L"Drivers\\Test\\myDriver", 0);

Using the handle returned, you can also force it to unload the driver. This means you can start (and stop) the driver without a KITL connection but allowing you to copy new versions of your driver on from an SDCard or ActiveSync, you'll need to rely on serial debug prints probably to debug here but it’s a quick easy mechanism if you don't have a debug transport.

2 comments:

Anonymous said...

Thank you, that was extremely valuable and interesting...I will be back again to read more on this topic.

Yash said...

I had read this a long time ago somewhere and had even tried it then. But this will only work for the Stream Interface drivers.

Make a stub stream interface driver say stub_actualdriver.dll. Have the entries of the above in the Platform.bib and the Platform.reg. From the Open of this driver call Loadlibrary or LoadlibraryEx with the name of the actual driver.

Debug the driver and in the close of the stub call FreeLibrary. Whenever one wants to debug a changed dll make sure the application has called close and then just replace the actual driver.

I might be rusty at many places. Please correct the post for any mistakes.

Regards
Yash