Problem running C samples for roboRio

[azaclauson]

I'm new to the roboRio and to feel my way around things I'm attempting to run the C samples found here http://www.ni.com/download/labview-r...-2015/5558/en/.

I can successfully build, deploy and execute a sample to the roboRio but the app fails when it attempts to initialise the FPGA. The exact error text is shown below.

roboRio Hello
ERROR: -61200
Could not Open FPGA!

The error occurs in the NiFpga_Open function when the application attempts to load NiFpga_RoboRioFpga10.lvbitx. The -61200 error code has a handy comment:

/**
* The operation could not be performed because the FPGA is busy operating in
* FPGA Interface C API mode. Stop all activities on the FPGA before requesting
* this operation.
*/
static const NiFpga_Status NiFpga_Status_FpgaBusyFpgaInterfaceCApi = -61200;

Unfortunately I don't know what steps to stop all activities on the FPGA. I've tried removing a few likely looking scripts from init.d but to no avail.

Should the C samples be able to work with the FRC roboRio firmware? And if so how do I get the FPGA into the correct state to run them?

[azaclauson]

I was able to solve my own problem by renaming the .lvbitx file in /usr/local.frc/bitfiles. I guess that stops the default image being loaded into the FPGA which means the C samples can then run.

Is there a way to unload the FPGA image from a roboRio bash terminal?

[euhlmann]

Does this option from the web dashboard work?

[azaclauson]

No it doesn't, that was one of the first things I tried as well .

[euhlmann]

Originally Posted by azaclauson

No it doesn't, that was one of the first things I tried as well .

That's disappointing. Have you reported the issue to FIRST? (If "Disable FPGA startup app" doesn't actually disable it, that would be a bug I think )

[azaclauson]

Originally Posted by euhlmann

That's disappointing. Have you reported the issue to FIRST? (If "Disable FPGA startup app" doesn't actually disable it, that would be a bug I think )

Where should I report it? Here http://forums.usfirst.org/?

[fsilberberg]

Originally Posted by azaclauson

Where should I report it? Here http://forums.usfirst.org/?

Please submit bugs here: https://usfirst.collab.net/sf/tracke...cker.4_defects

[azaclauson]

When attempting to create a new account on the TeamForge project I get the message below:

Permission Denied
x You have created the maximum number of users permitted for your TeamForge instance.
To purchase additional user accounts, please visit: http://www.collab.net/products/ctf/getlicensekey.html

[fsilberberg]

We're looking into it. I'll post again when we've resolved the issue (issue referring to the sign up limit).

[fsilberberg]

The Collabnet user issue has been fixed. However, something important to note: with the FRC image, this behavior is likely not a bug. The FRC Network Communications stack depends on the FPGA image, as the FPGA is disabled without an enable signal coming from a Driver Station. If teams were able to disable the image and load their own, they could bypass this behavior.

[euhlmann]

Originally Posted by fsilberberg

The Collabnet user issue has been fixed. However, something important to note: with the FRC image, this behavior is likely not a bug. The FRC Network Communications stack depends on the FPGA image, as the FPGA is disabled without an enable signal coming from a Driver Station. If teams were able to disable the image and load their own, they could bypass this behavior.

Then why is there a "disable fpga startup app" option in the first place?

[Greg McKaskle]

The roboRIO and other NI RIO products are used for more than FRC, and that includes loading your own FPGA bit file like the original poster is attempting to accomplish. The setting in question on the web page is useful for folks who have built a startup FPGA bitfile and no longer want it to be loaded at startup. It is confusing because there is no feedback as to how the FPGA is being loaded, so this option sounds good, and works in the right situation, but it isn't the option you are looking for.

For FRC, the bit file is loaded by the comms process, so the for nonFRC experimentation, I'd probably turn off the FRCNetComm daemon, reboot, and you'll be able to load your own FPGA for offseason, non robot, safe experiments. You can turn it back on or reimage to get things ready for FRC use.

Greg McKaskle

[azaclauson]

Originally Posted by fsilberberg

The Collabnet user issue has been fixed. However, something important to note: with the FRC image, this behavior is likely not a bug. The FRC Network Communications stack depends on the FPGA image, as the FPGA is disabled without an enable signal coming from a Driver Station. If teams were able to disable the image and load their own, they could bypass this behavior.

I still get the same error message when trying to create a new Collabnet account at https://usfirst.collab.net/sf/sfmain/do/createUser/.

Disabling the /etc/rc5.d/S88FRCNetComm did stop the FRC FPGA bit file loading and allowed the NI roboRio C samples to run.