dpcutil.dll crashes when closing under Win 7, 32 bit

[AndrewO]

I'm hoping someone can help me or tell me where to look.  I'm having an issue with two in-house applications.  When I free the dpcutil.dll DLL while using Windows 7 (32 bit) my application crashes.  I have this issue with versions 2.16, 2.13, 2.8 and 2.3.  It's only with the 32 bit version of Windows 7, the 64 bit version of Win 7 does not have a problem, nor does Windows XP.  It appears to manifest itself after the DLL is opened and closed a few times by a separate thread in the application.  If I don't close the DLL (i.e., free it), I don't have the issue, but the way we use the applications it is easier for us to open the DLL only when we need to use it and then close the DLL.  Has anyone experienced this and have a work-around?

[jpeyron]

Hi AndrewO,

I'm comfused about what program you are you talking about? please clarify so we can better assist you.

 

thank you,

 

Jon 

[AndrewO]

Jon,

Sorry.  After reading what I wrote, I guess you're right that there isn't quite enough information.  I also collected some additional data since I posted this question, so I will try to provide additional details below.

I install ADEPT using the executable "digilent.adept.system_v2.16.1.exe" for the 64 bit version of Windows 7.  I install ADEPT using "Digilent.Adept_v2-3-0.exe" for the 32 bit version of Windows 7, because I am getting the best results with that version.  I use "DAV1-10-0msi" for the Windows XP operating system.  These installation programs install the ADEPT application and the dpcutil.dll file in the ..\Windows\System32\ folder.  I believe it is the driver that I am having a problem with. 

We have two programs that we use in house where we need to access the Digilent JTAG device.  The two programs are usually open at the same time so we cannot leave the driver open all the time otherwise the two programs can conflict with each other.  One program loads the hex file into our Xilinx Virtex 5 FPGA and the other monitors the Device Under Test (DUT), i.e. the FPGA bitmap with the loaded and running hex file.  In order for us to have both application files open at the same time, after the hex code is loaded by the loader, the loader frees the DLL.  Then we can start monitoring the DUT with the other program.  If we need to reload, then we manually disconnect the application and free the DLL from the monitoring program and open the DLL on the loader application.  The opening and closing of the DLL are normally done in a separate thread, so the applications can do other tasks. 

What I am finding is that the programs have different levels of stability on the different operating systems.  The source code for the applications on the different operating systems is the same, but the DLL is different.  I don't need to run the two applications for the program to be unstable.  I usually just use the loader for debugging this problem.  The applications appear to crash at the point where the DLL is freed and the thread is completed.  The application is fairly stable on Windows XP and the 64 bit version of Windows 7, but the 32 bit version of Windows 7 seems very unstable.  I believe that the issue lies in the freeing of the driver and I think the stack is getting messed up.  I figure that this is the problem because I did the following test: I put a loop just before the end of the thread and in that loop, I load the driver, wait 500 mS, free the driver, and wait 500 mS, and so on.  I put the delays in because I seem to be able to make the applications crash faster (with less iterations) when there is no delay.  Longer delays seem a little better than short delays.  I can do anywhere from a couple of hundred to maybe 1500 iterations on XP and 64 bit Win7 before they crash.  It generally takes only a few iterations for the application to crash under 32 bit Windows 7.  I can certainly tolerate a crash after a few hundred iterations, but not after only a few.  By the way, if I run the loader application and never free the DLL in the thread and continuously run the thread and load the hex file, the application never appears to crash.

Has anyone experienced any instability with the dpcutil.dll under the 32 bit version of Windows 7 or any other OS?  Does anyone feel the need to use an older version of the driver to achieve stability under 32 bit Windows 7?  Is there a problem with continuously loading and freeing the DLL?  Am I using the latest DLL.

Thank-you for any help you can provide.

Andrew

[malexander]

Hi Andrew,

Have you tried running the 32-bit version of dpcutil.dll on a Windows 7 64-bit OS or are you only using the 32-bit dll on the 32-bit version of WIndows 7?

If this is a new application that you are writing with the Adept 2 SDK then I strongly recommend abandoning the use of dpcutil, as it is implemented in Adept 2 as a wrapper library that exposes the old Adept 1x API. The actual implementation makes calls to the DMGR and DJTG libraries, which provide the current API for enumerating and opening an Adept device and enabling a JTAG port and performing JTAG data transfers. If you switch to the Adept 2 DMGR and DJTG APi's you will not need to constantly load and unload the DLLs to allow access to a device between one or more processes. Instead, you can load the DLLs one time, use DMGR to open a handle to the device you wish to communicate, call DjtgEnable, perform the required JTAG transactions, then call DjtgDisable on the handle. Your second process can then open a handle to the same device, enable the JTAG port, and perform JTAG transactions. You can have an open handle to the same device in multiple processes but the JTAG port (port 0) can only be enabled on one handle at any given time.

We can try debugging the issue you are describing. I'm not sure why the Windows 32-bit version would exhibit this problem when the 64-bit version doesn't. To the best of my memory the source code is identical for both Windows versions so I would expect a problem in the 32-bit vresion to also be present in the 64-bit version. One thing I can tell you is that each time you load the DLL and attach a process to it DllMain gets called and the library initialization routines are run. The Adept Runtime is complex and the initialiation process requires the creation/opening of several different named semaphores, named mutexes, and shared memory segments. In my mind sitting in a loop loading and unloading the libraries a bunch of times is a very inefficient way to use our libraries.

When this crash occurs, is it after you've loaded the library, called DpcOpen, and then unloaded the library? If so, are you closing the device handle before you unload the library? Please let me know.

Thanks,

Michael

[AndrewO]

Michael,

Thank-you for the response.  I apologize for not reading it until today, but I decided to abandon the 32 bit version of Windows 7 for now because the machines are 32 bit architecture and we are having some other issues.  I might get back to it in the future if I have time.  However, your explanation of how the driver works and your suggestion about switching to the Adept 2 DMGR and DJTG APi's might come in handy.  In fact, I am having another issue with Windows 7, 64 bit that we did not experience with windows XP.  I wonder if going to the new API's will help the issue. The issue is that I run a series of tests over and over for several hours and at some point, the test application crashes and a window is displayed with some information about the crash and one item is "dabs.dll _unloaded."  Are you familiar with this error?  If you are would the new API help?  Would you be able to tell me where to find the documentation on using the Adept 2 DMGR and DJTG APi's?  Do you have any sample code on their use?

Best Regards,

Andrew

 

[D@n]

You can find the documentation for the Adept 2 DMGR and DJTG API's in the doc/ folder within the SDK, which you can download here.

I do have an example that you can look at as well, but only of the DMGR and DEPP interface.  You can find that in the S6-SoC project on opencores, and specifically the deppi.cpp (and .h) file.  (You might find the Makefile valuable as well.)  Within that project, I used the DEPP interface to drive a wishbone bus within the CMod-S6 device.  This required using the DMGR interface to get access to the DEPP port.

Perhaps someone else can pipe in with a DJTG example.

Dan

[AndrewO]

Thank-you Dan.  I'll take a look at what you suggested and I'm sure I'll have more questions.  The code we are using here was written some time ago by someone who is no longer here.

Best Regards,

Andrew