Quick disclaimer: I am not a programmer on the team, but I do some electrical work. 5 years FRC experience. And yes, I know the NI number to call – I plan to have the programmers call during tonight’s meeting since they know more about it than I do.
The problem:
Basically, we bought a roboRIO back a month ago or so, and that one works just fine. The brand new one in the KOP worked fine for two nights of testing (and driving on a 2013 robot), but then last night we ran into a bug. It stopped working :ahh:
Copy pasted from the programmers:
-Imaging doesn’t work.
-22 is closed, and 80 & 443 don’t work (hangs in browser).
-Holding reset starts it back in “safe mode.”
-Then, 22 works, but 80 & 443 still don’t (presents an error).
-Updating firmware doesn’t work.
In both modes, web-based control doesn’t work, and you have to use the USB cable.
FTP rejects all users in both modes.
Any help is greatly appreciated – have any other teams run in to a similar issue? To our knowledge, the RIO hasn’t been set on any motors/magnets, and there are no metal shavings anywhere near it at all. We’ve checked the wiring, and it all should be correct according to diagrams, but we forgot to check the actual voltage coming into the RIO with a multimeter (but it worked fine exactly as it is setup for 2 nights, then randomly stopped…). Also, all of the above testing is with only power connected to it – no sensors/Talons/etc.
Fortunately we have a backup roboRIO, but since we don’t know what happened to the first one, we can’t really prevent the same from happening to our second one… Thanks!
NI, and the rest of us, are going to want to know what you were doing immediately prior to everything breaking. Were you flashing firmware? Did you download new code? Knowing a probable cause for what broke things will help narrow things down.
EDIT: Also, there’s a lot of NI people on here at all hours. I’d recommend having your programmers also check in on this thread during the day if they get a chance.
If you haven’t done it already, please contact NI support directly via either the forums or a phone call. They would like to get more information on what caused the issue and they will help walk you through reimaging so that the device fully boots up.
Sorry for the delay – we worked on trying on our own last night with several different computers, and couldn’t get it to work. Called NI, they gave us some more ideas to try, installed more software on two more computers, then the guy had to go (they closed) and we tried without him with the new software – still nothing.
So tonight we called back and they gave us a whole new case number, said the old one had expired because 24 hours had passed (what? a week I get, but 24 hours? c’mon…). Anyway, they then tried to transfer us to tech support but then said they had actually just closed (an hour early…) and so we tried calling back but they wouldn’t push us through.
So, fortunately we’re still up and running with the second roboRIO (which is why I’m not too concerned right now) but we plan to call them as soon as they open tomorrow and get something worked out. Once we get it working, I’ll have one of the programmers jump on and explain what the solution was so if anyone else has an issue similar, they too can get it resolved.
I’ll look into the issuing of new SR numbers - they should NOT be “expiring” like that. Also the early closure - were you taking into account Central time? If so, and you in fact couldn’t get through during support hours let me know and I’ll follow up with the support team.
Hmm… OK, assuming you can get to a mode where port 22 works, log in via ssh (e.g., putty on WinDoze) as “admin” with no password. Once you’re in, issue the command “dmesg” and capture the output. Then paste that into CD so we can take a look at the output of the boot cycle.
Additionally, do you have the serial port hooked up by any chance? If the serial console is enabled, you should be able to capture the boot sequence via Hyperterm, putty or some similar terminal emulator. That info would be most useful in determining what’s going on during the Linux boot cycle. At least with that, we should also be able to see the boot loader code running.
I thought I should post here as one of the two programmers on Team 2059. A few things: port 22 is closed (nmap -A). Interestingly, the web interface shows that sshd is disabled. The other programmer and I are sure we never turned it off, via bash, or the web console.
Also, port 21 is open (with vsftpd supposedly running). However all connections are refused, including telnet, nc, and filezilla. Obviously if we could get a shell, there’s a lot we could do towards fixing the problem.
One last thing. This might be crazy, but is it possible to boot off of a USB stick? This would theoretically allow us to boot an arch/Ubuntu minimal USB, mount, and chroot in.
That is possible if they’re using the right version of U-Boot. Unfortinately, I don’t have my RoboRIO here, so I can tell you if it’s the right version. But, you should also be able to boot via TFTP over the network. Hook an RS-232 up to a terminal emulator and see if there’s a boot console that’s visible. It’s probably 115Kbps, N, 8, 1 for communications parameters. If you can get to a boot console, then you can completely reflash this beast.