Reasons for PC Crash?

[Stu_E]

Would it be possible to get a list of possible reasons for a PC crash?  It would be very useful for debugging a hard PC crash without any visible error codes and I think it would be useful to IF-RIO members who like me are trying to fix a crash error.

Specifically my problems is:

My app works in simulation, however when I try to run it on the Hardware it crashes the PC.  It appears to be the host-app since I can run the FPGA individually by clicking the start arrow on the FPGA Front Panel, but I am having a hard time debugging it and as far as I know I'm doing the same thing as the examples (down-converter & FIFO).  I'm not really sure where to begin. 

The purpose of the application is to capture raw data from the ADC and save it to a file.  The FPGA code is very simple it reads I&Q from ADC0 and then writes each to a separate FIFO.   The FIFO's are configured to be a large as possible 256, I16 elements each.  The host app has two threads (Producer Consumer Arch) one that reads the FIFO and puts the data in a Queue (the Producer) and one that reads the data out of the Queue and writes it to a file.  This was done to try and isolate the fast reading necessary to keep up with the FPGA/FIFO from the slow file writing.  Currently the Consumer/FileWriter runs the Producer/FIFOReader by reference, so that it can run on its own thread.

The project was started with the using the 'template approach' on page 20 of the 'Getting Started Guide' and it shares the ni5640R template.lvlib' with another project (via. a the *shared* directory provided in the attached zip file).  The folder titled *RawCap" is the main project directory with the project file.

Any help would be greatly appreciated.

Kind regards, Stu E

[Kyle_A.]

Hi Stu,

What specifically is the PC doing when it crashes?  Are you seeing a blue screen, black screen, is LV just crashing only, does it crash and then reboot?  This may provide additional insight into what to look for on the programming side.

I believe the best first step we can try to do to debug this crash would be to start minimizing your code to the smallest possible that still reproduces the crash.  Try to compile all of your host code into a single VI and see if that changes anything.  You mention that you are using references to run in its own thread, try eliminating the references and bring in the code as a subVI or a minimized portion of the code which will still make the program run properly. 

[Stu_E]

Kyle, 

Thanks for getting back to me.  I get a black screen and the entire PC locks up.  So far I haven't been able to do anything with the PC and I have to do a Hard reset.  I've watched the application code (using highlight execution & retain wire values) and everything looks fine up until the host application does the first FIFO read and that is when it crashes.  

The other thing I've noticed is that the FPGA front panel never starts 'running' like a traditional LV application, yet the 'Invoke.Run' command in the Host-application returns a message saying the FPGA is already running.  So it seems like the FPGA isn't running properly, when I launch it from the host application, but it does run properly if I start it by itself, by clicking on the start arrow.

I will try to build a simple test that repeats the error and report back.  

Thanks,

Stuart

[philippe_w]

Stuart,

In regards to the FPGA front panel not 'running': When you run the FPGA VI's front panel via the run arrow, the VI runs in "interactive mode" by: 1) downloading and running the bitfile and then 2) continuously updating controls and indicators on the front panel from the actual values present on the FPGA.

When you open a reference to an FPGA VI and run it on a target device, the bitfile is downloaded and run, but all access to controls and indicators is done through the read-write control nodes. The FPGA front panel is not "run" and does not continuously update the front panel display.

~Philippe

[Stu_E]

Philippe, 

Thanks, that is good to know, I was a little worried about the disconnect.

Stu E.

[Stu_E]

Kyle, 

I was able to repeat the error by only running the 'producer vi' (titled *FIFOReader*), which opens the FPGA, configures the hardware, reads the FIFO and enqueue's the data.  This eliminates the 'vi server' and the 'consumer' loop which dequeues the data from being the issue.  BTW, all of this runs fine in simulation (except the HW configuration calls which crash in simulation and I don't call in simulation - they are in a case structure tied to a global boolean).

I also noticed an odd Project Dependency in my LV project, noted in the attachment.  It appears that LV updates the ni5640r template library files whenever something in the project changes (I haven't identified what the pattern is yet, but it doesn't look to be exclusive to the template library files changes or even the library callers, which puzzles me).  The troubling thing I noticed is that when it 'saves' it doesn't completely update all of the library files.  I can fix this by opening the ones that didn't get updated, with the correct project open and saving them, but if I close one project (after everything is fine) and open the 2nd project the issue is repeated).  I was also puzzled why my project was pointing to the driver installed template library (C:\Program Files\...) and my tailored one, fearing that I altered the original I reinstalled the 5640 driver and cleaned up the project files to point to the correct template library (remove & replace the '5640r template.lvlib' seems to do the trick for the template, then I have to manually reset the links to my subvis.  After all this I completely separated the ni5640r template libraries for both projects (out of fear mostly not knowing what LV was doing that required 60 files to be saved, so they are no longer shared) and the problem (pc crash - the same as before) is still repeated.

Kind regards,

Stuart

[Kyle_A.]

Hi Stuart,

It looks like we are getting closer to finding the source of the crashes, so I have a few other steps I would like you to implement.  Can you try your code without the queue to see how results change?  You can put the data coming out of your reads into an array just to see what results.  Then, we can narrow it down to either the reading process or the configuration process that is causing crashes.

Another step that would be useful is if you have another PC you can try this code on.  Sometimes, system crashes can be PC specific, so if you can verify this particular code crashes a second computer it may help us determine if the PC you are on now is experiencing hardware issues or memory issues. 

[Stu_E]

Kyle:

Through some rigorous (and painful) testing, I've been able to identify the following things which cause a crash.

PC crashes (Hard PC crash, which is completely froze, Black screen on PC):

1. LV Driver examples run with Highlight Execution, will crash the PC
2. FPGA Example unchanged (Analog Input) run with 25 MHz Span
3. DMA FIFO Depth smaller than number of samples being acquired
4. DMA FIFO Depth configured (greater than number of samples), but FIFO hasn't been 'started' and data has been written by the FPGA, when first Host-app read occurrs memory is reallocated, causing a crash
5. Overflow (not confirmed, but strongly suspected, in all my testing I never saw an overflow indicator, but am pretty confident I have had a crash due to overflow (i.e. fpga writing data to a fpga-host dma fifo faster than the host can empty it)

LV Crash (LV crashes, but PC remains up and running):

1. Running LV in Simulation mode and calling a Driver setup function call, such as Configure TimeBase or Configure ADC

Stu E