Software Reset of FPGAs possible?


I have an application where I have two XEM7360’s connected to a PC and I’m reading them both out in parallel with a multithreaded C application. I am trying to track down a bug that causes the FPGAs to time out, but the problem is that I’m working remotely and sometimes when the FPGAs time out they can no longer be recognized again without a power cycle.

When I look in the device manager it says that the USB device crashed unexpectedly and is no longer recognizable.

So, is there any way to force a software reset or something similar on these ports to get them to be recognized again? I tried to Scan for USB devices in Frontpanel but that doesn’t do anything. Restarting works for one of the two devices, but not the second. A power cycle always works, but that requires me asking someone else to unplug them every time this bug happens.

Thank you.

Are you performing larger reads on a blockpipeout or a normal pipeout? Can you share any information regarding the errors you receive from your application?

More information about your setup could be helpful:
-Information about your host PC, make and model?
-Host operating system?
-FrontPanel SDK Version?

Unfortunately, there isn’t software reset functionality. You’ll need to manually power cycle it for the time being.


I am performing a 4 MB read on a block pipe out with block size 16384 B. I’m getting a Error Code of -1, which from the error code page is a non-descript lower level error.

I’m using a workstation with the following parameters. I’m not sure which version of the SDK I’m using … how do I find that out? I downloaded it a few months ago.

EDIT. Looks like I’m using 5.2.2. At least according to my FrontPanel Help window.

EDIT: I updated to 5.2.4. It didn’t fix the issue.


One other thing – when this happens the device serial numbers get corrupted. So I can’t open them in the C code.

You seem to be experiencing a number of levels of corruption or issues with this set up. In cases like this, it’s important to simplify as much as you can to determine the root cause, then build things back up.

Multithreaded applications can add a lot of complexity that is not easy to trace. Our suggestion is to reduce the problem to a bare minimum, testable, repeatable situation with a single board, single-thread, and very basic structure. Then increase the complexity until you find the fault.

Yes, I’ve done that. I removed all multithreading, a single board, and very basic structure. It works for a bit, then I get a -1 code error on my readfromblockpipeout function once, and then it repeatedly fails.

There is very little information on what a -1 error even means… is there any more information besides a non-descript low level operating system error?

Unfortunately, no. This is generally considered an unrecoverable error that happens at the lower levels of the USB system beyond our reach or control.

Are you able to repeat this issue with the PipeTest sample and specific parameters?

Not immediately, but I will continue trying.