Device Power Off Causes Device Driver Lockup

FrontPanel
1

Hello,

I’m back again, now that I’m delving back into the mysterious “lockup” problem that I visited several months ago, and was never resolved… So here it is… hardfail every time occurs during large pipe transfers when the hardware goes away… In the debugger my code is stuck in an endless loop…

sequence is D58, D5B, D5F, Jump to D9D, DA0, DA3, DA6, DA9, DAC, DAF DB1, DB5, jump to D58…

here is the code…

10016D58 mov edx,dword ptr [ebp-14h]
10016D5B cmp byte ptr [edx+1],4
10016D5F jne CCyUSBConfig::CCyUSBConfig+0B2h (10016d9d)
10016D61 push 4Ch
10016D63 call operator new (1001789e)
10016D68 pop ecx
10016D69 mov dword ptr [ebp-1Ch],eax
10016D6C and dword ptr [ebp-4],0
10016D70 test eax,eax
10016D72 je CCyUSBConfig::CCyUSBConfig+98h (10016d83)
10016D74 push dword ptr [ebp-14h]
10016D77 mov ecx,eax
10016D79 push dword ptr [ebp+8]
10016D7C call CCyUSBInterface::CCyUSBInterface (10016a82)
10016D81 jmp CCyUSBConfig::CCyUSBConfig+9Ah (10016d85)
10016D83 xor eax,eax
10016D85 or dword ptr [ebp-4],0FFh
10016D89 inc dword ptr [ebp+0Ch]
10016D8C mov dword ptr [edi],eax
10016D8E add edi,4
10016D91 inc byte ptr [esi+29h]
10016D94 mov eax,dword ptr [edi-4]
10016D97 movzx eax,word ptr [eax+4Ah]
10016D9B jmp CCyUSBConfig::CCyUSBConfig+0B5h (10016da0)
10016D9D movzx eax,byte ptr [edx]
10016DA0 add dword ptr [ebp-10h],eax
10016DA3 mov eax,dword ptr [ebp-10h]
10016DA6 cmp eax,dword ptr [ebp-18h]
10016DA9 lea ecx,[eax+ebx]
10016DAC mov dword ptr [ebp-14h],ecx
10016DAF jge CCyUSBConfig::CCyUSBConfig+0CCh (10016db7)
10016DB1 cmp dword ptr [ebp+0Ch],8
10016DB5 jl CCyUSBConfig::CCyUSBConfig+6Dh (10016d58)

just a guess, but it looks like the device driver missed the exit que…

Anybody got any suggestions where to look, while I’m boiling my code down to the minimum reproducable set?

Also, hope you got your order for Qty 60+…

Thanks,

Bill

2

Bill-

Using PipeTest setup for 8192kB packets and a 32768kB transfer on Windows XP, if I detach the hardware during a transfer, I get a message like:

WireToPipeIn(…) failed.

PipeTest was not written to handle the case where hardware is disconnected, so it still tries to do UpdateWireOuts and so on. These give unpredictable results, but the software does not crash. In particular, I can “Configure FPGA” again and it works fine.

3

OK, I found I was not looking at the return from the pipe for -1.
(You really should doument this in the .h file, isn’t this a relatively new feature?)
This solved the problem most of the time… (you really can crash the app and possibly the machine this way) (note that I am currently using a loop with repetitive calls to the fifo to get my data (which is pitifully slow))

I still get an very occasional “C5” exception (pointer to nowhere) in memcopy, and an “F8” illegal instruction… is this the updateWireOuts problem you refer to? Could the buffer I supplied to the pipe be corrupted somehow? What is the best way to detect the driver has gone away? (since hardly any of your routines return status?). I’m currently using GetDeviceCount()… I guess I need to do this before every call to the driver? Do you have an example written to show how to another way to handle hardware disconnect?

Help is appreciated!

Bill

4

Hi Bill-

The (-1) return value has been in the code and documented since the first release. The true API documentation is the API reference which is available online in HTML format. It is also installed with the software and called “API Reference” under the Opal Kelly / FrontPanel startup menu group. The header files provide no documentation aside from a very brief summary of each method.

As was mentioned in this thread:
http://forums.opalkelly.com/showthread.php?t=152

the proper way to handle device disconnect under Windows is to check for the WM_DEVICECHANGE event. Please review that thread for more details. We do not have an example of that particular handling.

A bit of Googling and I turned up this example:
http://www.codeproject.com/useritems/HwDetect.asp

MSDN probably has several examples, as well, depending on your setup. The handling varies depending on programming environment, but the principle is the same – when you receive the WM_DEVICECHANGE event, you know that the USB device tree has changed. This is the only time you need to re-check your assumptions regarding the “existence” of your device.

5

Hi Jake,

Thanks for the article. I know I couldn’t get ahold of the message before, perhaps I didn’t have the proper library? Anyway I took your excellant suggestion from the 152 thread and got myself an MSDN subscription some months ago, and that has been hugely helpful everywhere, so now I guess it is time to apply it… Here. I’ll get back back later and let you know what happens. Just a suggestion though… it would be nice if you could wrap the message handler function in your library/dll so you can distribute it, and maybe leave the user just a variable to check or something simple like that…

Thanks again,

Bill