Download Failed Means that is did not connect to the bot.
Did you:
connect to the system in the (default location) lower left target sys box?
set the download options (enter FRC_UserCode… and {Options=0x1000010}?
if not the second one, right click on the project on the left, and Debug/Run kernel task, and put in the info in the C_Programming_Guide.pdf (i bileve that is the name) specifies.
If you did both, can you ping the cRIO?
I don’t know what you mean by ping the cRIO (with cmd prmt?).
I do connect and disconnect just fine.
Everything is set up including the advance options string. (Although it didn’t appear in the manual). Am I reading an old manual?
Still no luck though.
ping cmd:
Microsoft Windows [Version 6.0.6000]
Copyright (c) 2006 Microsoft Corporation. All rights reserved.
C:\Users\James>ping 10.17.99.2
Pinging 10.17.99.2 with 32 bytes of data:
Reply from 10.17.99.2: bytes=32 time<1ms TTL=64
Reply from 10.17.99.2: bytes=32 time<1ms TTL=64
Reply from 10.17.99.2: bytes=32 time<1ms TTL=64
Reply from 10.17.99.2: bytes=32 time<1ms TTL=64
Ping statistics for 10.17.99.2:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms
When you download a module, vxWorks needs to connect all the unresolved references in your module.
For example, if your module calls a function named ‘foo’, then vxWorks must be able to find an address for ‘foo’.
The function ‘foo’ might be part of the vxWorks kernel or it might come from other modules that have already been downloaded.
Include paths are a compile time issue – where does the compiler look for header files.
Unresolved symbols is a link time issue (in this case dynamic linking) – the linker is unable to find some data object or function.
Of course, with C++ name mangling, it can be tedious to figure out where the unresolved symbols are supposed to come from.
It may be that you need to statically link your module to some library.