FPGA problem

Technical NI LabVIEW
1

Our team had recently encountered a problem regarding randomly occuring FPGA problems not allowing us to write values to the PWM ports after downloading our main robot code after turning the RoboRIO on. The solution we found for this problem was to restart the RoboRIO, download an empty project to it, and then download our main robot project.

This solution isn’t satisfactory, we don’t want to have to deal with restarting the RoboRIO during competitions, and we still don’t understand why, technicaly, this problem is happening. Any help shedding light on this issue would be appreciated.

2

Have you given NI a call about it? That’s what I would do first. It could be an issue with the RoboRIO and they can issue an RMA.

3

We don’t think its a RoboRIO problem because if we run an expample after a reboot our program works, but if we run our program first it doesn’t work.

We assume that our program has a problem with the configuration of the FPGA.

4

Your program can’t touch the FPGA. All of the FPGA code is written and included in the roboRIO Image you install with the rest of the image. It’d require a long time to recompile the code into the FPGA (minimum of 30 minutes) and I sincerely doubt you’ve ever seen this. (As far as I know, the FPGA module required to do this isn’t available to FRC teams and you’d break the functionality you require to talk to the FMS).

That said, the problem is likely elsewhere. You said the example project works. You also mentioned an “empty project.” Are these one and the same?

I’d be interested in seeing what you’ve got going on in your actual project that’s causing this.

As you said, I don’t believe that’s an acceptable solution as I’ve seen far too many robots reset on the field. If this is your solution, you’d lose the ability to boot back up on the field and a power hiccup would result in the rest of your match being a spectator affair.

Try to provide as many details as possible. Does this happen both when you hit the run arrow and when you build it and send it to the roboRIO for startup? Do you get any errors about specific PWM ports? Can you share the log from your Driver Station? (Just above the dialog window there’s a gear. Click it and choose View Log File. There’s a bit of information there including a list of events.)

Have you tried reimaging the roboRIO and see the same results?

Do you have a second roboRIO you can try this on and see if the behavior is the same? If not yours, is there another local team you can talk to just to run this step for troubleshooting?

5

Before I answer your questions I feel it is necassery to explain myself again, after reading my first post I realized I might not have been very clear.
A few days ago we found that every once in a while when running our code on the roboRIO we couldn’t send values to the PWM connectors. After a day or two of trying to figure out a solution, we noticed that if, when we run first code after activation, we run an empty project, and then download our main project, there is no problem.

Now that I’ve made sure our problem is clear, I can answer your questions.

You also mentioned an “empty project.” Are these one and the same?

The empty project is the default, freshly opened, FRC roboRIO project. The example project is example code for specific PWM components from the “Find FRC Examples” tab in Labview (Servo code for example).

Does this happen both when you hit the run arrow and when you build it and send it to the roboRIO for startup?

We haven’t built our project yet, as we are still in debugging process.

Do you get any errors about specific PWM ports?

We did not get errors about specific PWM ports and as i’ve stated, when this error occures none of the PWM ports work.

Can you share the log from your Driver Station?

I currently don’t have access to the robot and won’t have for the rest of the day, I do have a picture of the log:

file:///C:/Users/BumbleB/Desktop/20170222_220945.jpg

Have you tried reimaging the roboRIO and see the same results?

We have tried reimaging the roboRIO and we’ve seen the same results.

Do you have a second roboRIO you can try this on and see if the behavior is the same?

We’ve tried running the code on a different roboRIO and the error still occures.

6

https://mail.google.com/mail/u/0/?ui=2&ik=cf26ef4627&view=fimg&th=15a6ccbd346dcd82&attid=0.1&disp=inline&realattid=1560159323598880768-local0&safe=1&attbid=ANGjdJ_Kgwhd5dB74LSy5C1kVeC4fEzz0RAKJyqHR1yI5XB-8dF3OfRpASsIhAqGwBsFSjleQv0n0iTtmfrDDnF3Wp-gzXK8c2CGGlCSRua5Z7jIMl8t5XwiG2MB8o0&ats=1487884552483&rm=15a6ccbd346dcd82&zw&sz=w1920-h887

7

This should work :slight_smile: Sorry for struggling to upload a PNG to the internet :slight_smile:

[Album] Imgur

8
9

No need to apologize about the pic. CD takes some getting used to in that respect.

That’s one entry from the log. I’d be curious to see what else shows up there. (the gear shows all entries from the run as well as ton of other information about your bot: battery throughout the match, when you connect/disconnect to the radio, etc)

When you get that warning, are you able to restart the roboRIO and run your code without any issue or do you HAVE to choose the other project to ensure success?

Is that the only error you’re seeing?

With the reimage and two roboRIOs showing the same behavior, I’d tend to agree the issue isn’t something with the roboRIO that could be fixed with the RMA (return) process. We’re seeing it across roboRIOs.

In a quick search, I found something here: https://www.chiefdelphi.com/forums/showthread.php?t=135103 Do you have any VIs that are giving you a hard time that might have corrupt components in them?

If you don’t see anything obvious, it might be worth bringing functionality from your project into the default project in groups to see if that brings the error with it. That can help narrow down where it’s coming from.

It’s a bit unclear if you always see this behavior or only see it sometimes. Is this something you’re able to force to happen for troubleshooting or is it “try this and hope it works. We’ll find out randomly later if it didn’t”?

10

Update:
The problem is with the navX. Yesterday we decided to copy our entire code one system after the other, and run the robot after each copy. We discovered that only after adding our navX code the error appeared, so we copied everything but that. A day has passed since then and the error has yet to occure. This is very strange because we followed every single guide and tutorial there is regarding using the navX and it still gives us errors.

Any help?

11

Did you have to make stubs for the missing code, so the system would compile and run?

12

It would really help to have you post your labview project somewhere so we can review the code…

It’s starting to look like the issue is in the labview library, and this will help confirm that.

13

Good news; we now have a way to reproduce the issue. What needs to occur is to initialize the Expansion IO as shown in the attached image - without this initialization problems similar to what you are seeing will occur.

Also attached are two VIs that you will need to perform the initialization. Please follow these directions and let us know your results. That will give us confirmation we’ve got a resolution and we can incorporate this into an update.

Thanks.

14

We tried to put the VI’s in our code but we did not understand exactly where. At first, we put the InitExpansionIO VI in the Begin but it didn’t work.

In your InitExpansionIO you open only two AnlogIn but NavX has four AnlogIn inputs is that intentional or accident?

15

*AnalogIn

16

If any team that was seeing this problem can confirm that this resolved the issue that would be great. We are anticipating a new library release today with a new library for the expansion IO.