Is there a built-in way to upload an FPGA bitfile back off of a target?

[blackburnite]

There is some legacy code which had poor config management/revision control.  They've asked if there is a way to pull the FPGA bitfile off of the RT target.

Is there a way to do this given the following conditions:

- If the bitfile was directly deployed either through a LV project, MAX, or the RIO Device Setup utility

- If the bitfile was bundled into a RTEXE and deployed

- If the target path to the bitfile is not known and/or does not exist (such as if it was bundled in an RTEXE)

[GerdW]

Hi black,

---

@blackburnite wrote:

They've asked if there is a way to pull the FPGA bitfile off of the RT target.

---

Do "they" really want to LVBITX file? Or are they looking for the source code (aka VI files)?

---

@blackburnite wrote:

Is there a way to do this given the following conditions:

- If the bitfile was directly deployed either through a LV project, MAX, or the RIO Device Setup utility

- If the bitfile was bundled into a RTEXE and deployed

- If the target path to the bitfile is not known and/or does not exist (such as if it was bundled in an RTEXE)

---

You might try to use a file explorer (as provided by the web interface of your cRIO) to search for a lvbitx file on your cRIO filesystem.

I'm not sure that file will exist as I never had to look for it - using some SCC system (or simple backups) kept me sane…

[Jacobson-ni]

---

@blackburnite wrote:

- If the bitfile was bundled into a RTEXE and deployed

---

If I remember correctly this one actually changes depending on the version of software you are using. If you build an RTEXE that calls Open FPGA VI Reference and links to some bitfile or build, the .lvbitx file is always built into the RTEXE. However, I believe there was a bug that would cause the bitfile to be copied over to the RT target even though it wasn't needed (I think the .lvbitx was right next to the .rtexe but I honestly don't remember).

[blackburnite]

They do want the compiled FPGA perosnality.

Yea, if it's a linux target I'll SSH to it and see if I can grep a lvbitx.  I'm guessing it's not though because this has "legacy" stink to it with the apparent lack of revision control among other things.

I'm not aware of anything that does a "one-click" reverse of the "Update Firmware" in max for an FPGA target but figured I'd see if someone knew of some long shot that I'd missed.

[blackburnite]

I've seen similar behavior to that on previous projects and I'm hoping that's how it is in this case or that the bit file was dynamically called with a path on the target.

From the sound of it though, I doubt that's the case since that would tend to be a more advanced application use.  I'm guessing this is a hacked together legacy code base with poor revision control that they are now trying to salvage and are probably SOL on.