It's about time I ask for help... How do you know if your cRio is fried?

So, some background, last year at BAE GSR our cRio was having problems and would run code that we had uploaded a good amount of time prior to competition, no matter how many time we would try to put in the current code. As you can imagine, this was very concerning, however we just dealt with it and moved on. This year I am trying to reimage the cRio (I have been trying for over a week now) and I am unable to. I have had team 1517 help me all day today (Thank you so much guys) but still it isn’t working, even though we followed the same steps they did and it was successful for them. Is it possible that our cRio is just dead? We didn’t get the new cRio this year, so we are using the old 8-slot one. Any ideas on what is going on? Is it just the cRio? And if so, how do we get another one?
Thank you,
Team 1721

Is it possible one of the modules is fried? I have seen fried modules do some crazy things.

Your original GSR issue sounds like the code failed to build, so the FRC_Communications library will load the backup code on the cRIO. When you download new code, the old stuff is kept and renamed, not deleted. This doesn’t mean anything is wrong with the cRIO, but with the code or the way it was built.

My suggestion would be to open default code, framework template code, or even example code. If it matches the wiring of the robot and doesn’t run, then it is likely a HW problem. If it runs and your code doesn’t, then that gives you something to focus on and may hint more to a code or isolated HW issue.

The cRIO is a modular system. This makes it possible to change out one breakout, one I/O module, or even to move things to another slot if a pin is bent.

At this point I have almost no description as to what has been tried and what works and what doesn’t. If you want us to help diagnose and correct the system, you need to give us accurate descriptions of how the system behaves.

Greg McKaskle