FPGA weird behavior on small, innocuous change

[MarkBowles]

Good morning, all,

I am maintaining and extending a LabVIEW application that runs on a NI 9067 cRIO. It's been running for several years, through a constant stream of mostly small, incremental changes.  The app has its own custom-coded FPGA.

In response to user requests, I added a single VI to the FPGA that queries a new 9219 A-to-D module, and places the result in the FPGA's interface, for the unix side to retrieve. The result was unexpected; the entire loop in which the VI was called permanently froze.

The new VI does have some iteration in it, so my first impulse was to zero out the iteration repetition count, which didn't help. I used Diagram Disable to remove more and more of the new VI's functionality, until it was nothing but an empty shell, with the error input being passed to the output, and constants providing the VI's other outputs.  The result was the same; the loop calling the VI froze. By this time, there was no reference in the surviving code to the 9219.

Just to make sure the problem wasn't somewhere else, I diagram-disabled the call to the new (empty) VI, and everything returned back to normal.

The FPGA is not close to capacity, according to a compile report:

The timing report is also benign -- all criteria "met".

Does this sound familiar?  Any suggestions as to what might be going on would be greatly appreciated!

Thanks,

-- Mark

[GerdW]

Hi Mark,

simple answer: when there is a problem in your code then you should attach some code!

A simplified version showing your problem is ok...

[MarkBowles · Accepted solution]

It's a bit of an overstatement to say I found the problem, but at least I eliminated it :-).

Since the VI that was causing the problem contained nothing but diagram-disabled code in it, my next step was to create a new empty VI and copy the code into it.  In the process of doing this, I found an error wire that curled under itself, which sometimes happens when you drag a VI around in a block diagram, which I cleaned up, but I don't think this changed the connectivity of the code.

The resulting version of the app did not freeze where it had been, and I'm back to normal debugging. It's still not working as I expected it to, but it's new stuff and there are likely "real" bugs in it, and I can no longer describe it as "weird."

Before I did this maneuver, I checked the VI Properties of both versions of the troublesome VI, and they looked the same, particularly the Execution properties.

So, bottom line, I don't know exactly what this problem was, but it appears to have been solved.

[billko]

---

@MarkBowles wrote:

It's a bit of an overstatement to say I found the problem, but at least I eliminated it :-).

Since the VI that was causing the problem contained nothing but diagram-disabled code in it, my next step was to create a new empty VI and copy the code into it.  In the process of doing this, I found an error wire that curled under itself, which sometimes happens when you drag a VI around in a block diagram, which I cleaned up, but I don't think this changed the connectivity of the code.

The resulting version of the app did not freeze where it had been, and I'm back to normal debugging. It's still not working as I expected it to, but it's new stuff and there are likely "real" bugs in it, and I can no longer describe it as "weird."

Before I did this maneuver, I checked the VI Properties of both versions of the troublesome VI, and they looked the same, particularly the Execution properties.

So, bottom line, I don't know exactly what this problem was, but it appears to have been solved.

---

If copying the code to a new block diagram fixed it, it was likely a corrupt VI.  You can be reasonably sure you found the error.