Another code download problem

[ofshea]

I've looked through a lot of pages, and I think our issue might be unique.

Symptoms:
Downloading works (I've watched it in Wireshark, and I can see the file in /ni-rt/system/)
Then we try to reboot the system, to run the downloaded code (using 'Reset Target').
And it never comes back! After a hard-reboot, it starts talking again, but it pretends that we never downloaded anything.

Things I've tried:
-Putting the .out into /startup (same results)
-Connecting over a serial connection (using the Windriver terminal) -- I don't seem to get anything (one empty line?). I've been sure to match the port settings etc. and it's on a standard port (COM1). It is using a serial/usb converter (from VEX I think), because the programming laptop doesn't have a serial port.
-Using the DefaultRobot binary, rather than our own code (same results)

Another note: sometimes we get messages like mikets' (http://www.chiefdelphi.com/forums/sh...d.php?t=83212), but not often (and I'm not sure in what context -- it's only happened once or twice).

Any help appreciated!

Thanks,
246

[ofshea]

I've gathered this additional tidbit:
If the robot has something "deployed" (it still won't run, but if we had downloaded before), we get the "relocation offset too large" (I have set -mlongcall) as in http://www.chiefdelphi.com/forums/sh...ad.php?t=83212 when we try running it in RAM. As soon as it's undeployed & rebooted, it works when we load it in RAM again.
Hopefully this will narrow it down some.

Thanks,
246

[mikets]

You may want to check your cRIO image to make sure you have the latest (v20) and also with matching Workbench update 4.3. Sometimes, I found it helpful to re-flash the cRIO image anyway (with the "format" checked), just in case there is something mismatching on the flash disk.

[Travis Hoffman]

I am experiencing similar problems - last year's code downloads and executes fine. Creating a new shell based on last year's project, writing new code, compiling it without issue, downloading it perfectly, and rebooting yields "no robot code". Extremely frustrating.

As far as I can tell, I've updated every and all piece of software and firmware to current versions. If there is a magic spiffy-dee-do installation order that must be followed in order to get everything to mesh properly, I don't see the corresponding magic spiffy-dee-do DOCUMENT that informs end users on what that process should be.

I am seeing a lot - too many - of these WindRiver "No Code" issues from many people of late - I did not have any problems at all with this using last year's stuff. Is anyone "in charge" doing anything constructive to address these issues, as some appear to still be stuck?

Also, I'd like to know (and I thought I knew, as I did it last year several times successfully) how to rename a project, the build paths/specs, yadda yadda from one project name to another. Example - "DefaultRobotProject" to "XM12", such that the end result is a binary XM12.out. Again, I did this last year in modifying 1114's beta test code with no major issues.

Disclaimer - I am not a hardcore C programmer.

Thanks in advance,

[gvarndell]

Originally Posted by Travis Hoffman

rebooting yields "no robot code".
Extremely frustrating.
I am seeing a lot - too many - of these WindRiver "No Code" issues

One symptom, unknown number of causes, no defined path for reaching a diagnosis. Mayhem. Little black boxes -- remember, you don't need to know what's inside.

[Alan Anderson]

Originally Posted by Travis Hoffman

I am experiencing similar problems - last year's code downloads and executes fine. Creating a new shell based on last year's project, writing new code, compiling it without issue, downloading it perfectly, and rebooting yields "no robot code". Extremely frustrating.

As far as I can tell, I've updated every and all piece of software and firmware to current versions.

If last year's code executes properly, that's a pretty good indication that you probably have last year's image in the cRIO. What does the Driver Station tell you the cRIO image version is? It had better end in v20, or you'll get "no code" indications when you try to run a program compiled against the most recent WPI library.

[Abrakadabra]

Travis and others -

The best thing you can do is download the NetConsole plugin and install it. (See link under "C/C++ Team Update 4.0" on this page). Watch the console when the cRio reboots. The messages are still a bit cryptic, but you should be able to glean hints about which pieces of code are complaining. You can then either change that code or just comment it out until you can get the rest of your code booting cleanly.

I too have seen a much greater sensitivity to little code issues that didn't seem to matter last year. Not sure exactly what the difference is this year. But I have found that using the NetConsole and the iterative process described above has helped get us through it.

Also, make absolutely sure that you have the latest cRIO firmware image and the latest WPILib update - the latest updates seems to have fixed a lot of the little stuff as well.

HTH.

[Travis Hoffman]

Originally Posted by Alan Anderson

If last year's code executes properly, that's a pretty good indication that you probably have last year's image in the cRIO. What does the Driver Station tell you the cRIO image version is? It had better end in v20, or you'll get "no code" indications when you try to run a program compiled against the most recent WPI library.

It's v20 on both the robot's cRIO and our demo board cRIO. Same effect on both. Latest DS software too, as well as latest WindRiver update.

I can run both last year's code (recompiled with this year's WPILib, without many changes) and also this year's 2010 camera demo code.

I copied in modified code from this year's project into the previously working .cpp and .h files from last year - no robot code resulted. I'm going to have to narrow it down slowly.

Originally Posted by Abrakadabra

Travis and others -

The best thing you can do is download the NetConsole plugin and install it. (See link under "C/C++ Team Update 4.0" on this page). Watch the console when the cRio reboots. The messages are still a bit cryptic, but you should be able to glean hints about which pieces of code are complaining. You can then either change that code or just comment it out until you can get the rest of your code booting cleanly.

I too have seen a much greater sensitivity to little code issues that didn't seem to matter last year. Not sure exactly what the difference is this year. But I have found that using the NetConsole and the iterative process described above has helped get us through it.

Also, make absolutely sure that you have the latest cRIO firmware image and the latest WPILib update - the latest updates seems to have fixed a lot of the little stuff as well.

HTH.

Thanks for the suggestions - I'll try to lock this down at the school tomorrow.

[Radical Pi]

Have you checked the WPI page recently for updates? If you aren't running the absolute latest download your code will crash and cause those errors if you try to use the DriverStationLCD or the AxisCamera class (depending on which update you are on)

[Travis Hoffman]

Originally Posted by Radical Pi

Have you checked the WPI page recently for updates? If you aren't running the absolute latest download your code will crash and cause those errors if you try to use the DriverStationLCD or the AxisCamera class (depending on which update you are on)

We are using the DriverStationLCD class, but I had installed the latest WindRiver update from the WPI site (4.3, dated 2/17/10) prior to the No Robot Code errors - is there any way to verify the update "took"?

I presume the updates are cumulative - installing the latest includes the changes built in to previous updates - can someone please verify?

[heydowns]

Originally Posted by Travis Hoffman

I am seeing a lot - too many - of these WindRiver "No Code" issues from many people of late - I did not have any problems at all with this using last year's stuff. Is anyone "in charge" doing anything constructive to address these issues, as some appear to still be stuck?

The plethora of "No Code" threads and issues stems from the simple fact that the "No Code" error indication (on the driver's station, primarily) is so generic and can have so many root causes.

This will be shown whenever something has occurred to make your robot code be non-functional. This includes, but isn't limited to:

1. Failure to load at runtime. The way code is built for the robot is unlike building programs for a computer or other environment -- the program isn't actually complete (at a low-level) until it is on the robot and "linked" at runtime with the other binary files present on the cRIO. If you have a problem in your program where you, for example, declare a function that isn't actually defined anywhere, you won't actually run into a problem until loaded on the robot. This can be the result of even a simple typo.

2. Crashing programs: if your program, has some sort of ill-behavior and aborts for any reason, it can be reported as "No Code".

3. Simply not having code on the robot

4. cRIO image version mismatches with version of Windriver updates. This is really just a special case of #1

5. Buggy Windriver updates - again, just a special case of #1, but has been much more prevalent this year.



Good practices:

Use debug, not FIRST->Download for most testing and development. Only use FIRST->Download once you get to a competition point and need code to run on robot boot up. The debug load will immediately report problems and point you in the direction of how to fix.

As suggested in another post, use the console! This can be:
1. Serial console over the cRIO serial port with the DIP switch toggled appropriately (not for Black Jag CAN users!), or...
2. Netconsole (works great - highly recommended!), or...
3. Target Console launched from Windriver (though this will not catch problems early in cRIO startup)

I presume the updates are cumulative - installing the latest includes the changes built in to previous updates - can someone please verify?

I can confirm proper operation of several of our laptops that had recent updates applied without prior updates applied; I do believe they are intended to be all-inclusive.

[Radical Pi]

Originally Posted by Travis Hoffman

I presume the updates are cumulative - installing the latest includes the changes built in to previous updates - can someone please verify?

yeah, you only need the latest update, not a problem if you missed one.

Also double-check whether you chose the right programming language in the cRIO flash window. If you have the wrong one the robot can't figure out how to run the code (another version of #1 of the poster above me)

[Travis Hoffman]

With the help of NetConsole (you're right - it's great - no more serial ports!), and some finagling of the unfamilar debug tools, and the help of people in this thread, I found out that.....drumroll.....

....I had declared a function but did not define code for it. A very basic d'oh. Wish that kind of stuff was presented more obviously to the *basic* end user.

Anyway, thanks again to all who provided advice and assistance in this thread.