Missing Source files when debugging F2812 DSP/BIOS v5.42 with CCS v6.1.0

Do you have any gel files running when you load the target with CCS 6.1 (and/or with CCS 3.3)?

Just to make sure we are on the same page. You have a .out (based on BIOS 5.42) and it works when you use CCS 3.3 on your board. But when you use CCS 6.1.0, that same .out does not always work on the same board...correct?

Or is that you 5.42 works and when you ported it to SYS/BIOS 6, you are having a problem? If this is the case, can you attach the 5.42 and 6.xx applications mapfiles? Which version of SYS/BIOS 6 are you using?

Todd

Sorry, I should've been more clear. I have a .out file that was build with CCSv3.3 & an earlier DSP/BIOS version (5.x, but earlier than 5.42). This was our production release of firmware in 2009 and It works solid in our hardware and the hardware is unchanged. Since CCSv3.3 is no longer supported and I need to make changes, I'm trying to port the project to CCSv6.1.0 and DSP/BIOS 5.42 for now, then to the latest version. There are no code changes to the project, just minor changes to the build settings to get the project to build without errors. I imported it first into CCSv5.5 and a couple of weeks ago into CCSv6.1.0 after I got new drivers for my Signum JTAGJet-C2000 emulator. I'm building now with the CCSv6.1.0, DSP/BIOS 5.42, and compiler v6.4.3. 

During debugging (stepping), the debugger tells me at points where it can't find code, that a particular source file is missing and as I step, it switches to other source files that it can't find. It's not all source, just some of the DSP/BIOS source that is missing. I've done extensive windows searches for those files and for functions within and they are not on my pc in C source format. It would be easier to trace the code and understand what's happening if I had those missing source files for debugging.

I have a couple of related issues when debugging this project. First, I'm trying to trace the stack. In doing so, I wanted to fill the stack memory with a particular value, and using the memory browser I can change individual memory values OK, but when I use the fill memory command and then look at the result, the memory was not changed at all-not even a single location. I even did a memory browser refresh but the result was the same. I also tried filling the data versus program memory but neither work.

As I'm doing stack tracing, I can see that at a certain point in the execution (during DSP/BIOS routines) the stack pointer jumps from 0x041C to 0x9B20, obviously overflowing the stack of size 0x2F0 starting at 0x400. I put a watchpoint for memory write near the end of stack at - 16 locations from the end (0x400 + 0x2f0) -16 = 0x6E0, but it never trips the watchpoint. I believe the stack size of 2F0 was suggested (calculated) by the DSP/BIOS config tool as a safe initial stack size.  I get different results when I just run versus stepping. When I run, the PC always goes to 0x000000 and the stack pointer has overflowed.

And as I said before, sometimes, especially after a program flash load, the new build will run correctly once or twice, but after power cycling, which shouldn't make any difference, it no longer runs correctly, even if I unlock the CSM first. Any suggestins would be appreciated. Thanks.  

I missed your question about the gel files at first. Please note, with the older working build, I'm only using the .out file built from CCSv3.3, and loading it with my emulator's flash tool outside of CCSv6.1.0, then running the code on my hardware which works great. With the new CCSv6.1 build, I build, flash, and debug all inside of CCSv6.1 and yes, I have a slightly modified standard F2812 gel file for which I commented out all the external memory locations as I'm not using them, like the ones one would find with the EZDSP F2812. I've reviewed the gel file contents carefully and the remaining memory map is accurate--all for internal RAM, FLASH, and the internal ROM.

Can you load the old working .out via CCS6.1 and confirm it works? When you run the new .out, does it get to main()?

Todd

Todd, this is a bit complicated to answer but here goes. The old working version of my .out file (from 2009, CCSv3.3) can be loaded (flashed) by using my Signum JTAGJet-C2000 emulator's own windows flash app, separate from CCSv6.1. If there's a way to flash that older .out file from CCSv6.1, I don't know how to do it as there is no project or source code associated with it. I could of course make a project for it, but I still would have no source code to build. To be more accurate, I have the source code, but I don't think CCSv6.1 supports the older DSP/BIOS version I was using in CCSv3.3 in 2009 (version 5.2.0.45). And even if it did, it might not build in CCSv6.1. ALso, with the CCSv6.1 version, I'm using DSP/BIOS v5.42. The only difference between the old and new versions is that the new CCSv6 version uses the newer DSP/BIOS 5.42 version. There are no other differences unless the CCSv6 importing tool (import from CCSv3.3) changed something.

When I load the new .out file, I can step to main() shortly after c_int00, and I can step thru some of the code in main(), but before I get too far, the code goes out to lunch. I've noticed that there seems to be a stack switch from 0x400 to about 0x9610 with 0x400 used for my code and 0x9610 used for DSP/BIOS. Is this the way it's supposed to work? Is there any way for me to get the missing DSP/BIOS source files that the debugger is looking for when I'm stepping thru the code?

Finally, I seem to have a problem with the CCSv6.1 Memory Fill command. I can run it, but it doesn't actually fill the memory locations I select no matter what I try as evidenced by the Memory Browser screen afterwords--even after a refresh in Memory Browser. Specifically, I'm trying to fill the stack at 0x400 up to the end of the stack with known values (like 0x0123) to help determine if I'm overflowing the stack. And I can change individual memory locations one at a time, but a memory fill simply won't work. Also, when I do change a RAM location value, I have to change the location two words higher in RAM than the location I want to change. For example, I have to change location 0x402 to change location 0x400 in Memory Browser. I don't know if this is an emulator problem or not. To check this out, I've just purchased an XDS200 that I should get by Thursday this week. But if I get the same results with memory fill and having to change memory locations that are two words high, I'll really be stumped.

Any help would be greatly appreciated.

It sounds like there is a fundamental problem with the emulation. You can load a program without a CCS project. Once a debug session has started, simply do a Run->Load->Load Program... and then search for the .out file. It would be interesting to see if that works.

Does your symptoms appear on a TI-RTOS example? Can you install TI-RTOS for C2000 (via App Center or here: http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/tirtos/index.html)? Then in CCS Resource Explorer, you can find the 2812 kernel examples. Build and run any of these.

note: TI-RTOS contains SYS/BIOS. We are rebranding SYS/BIOS as TI-RTOS kernel. TI-RTOS contains other things also (drivers, instrumentation, etc.).

Todd

Todd, Yes, I have TI-RTOS installed. I finally figured out what the trouble was in my project. There was an incorrect load address location for .hwi-vec and now the project seems quite solid. My goal was not just to rebuild the old project, but to go beyond by updating to SYS/BIOS and then make changes. But I still have the following problems/Issues:

1) The Memory FIll will not work.

2) When using the Memory Browser to change a Memory location's value, I must click on the location 2+(desired memory location), which then changes the desired location.

3) I'm severely handicapped in debugging without trace ability, which I apparently will not have unless I update my DSP/BIOS to SYS/BIOS.

Regarding these issues, I've purchased a new emulator (XDS200) that I expect tomorrow or Thursday so I can test if I have emulator issues. But regarding the lack of RTOS Analyzer functions currently, is there any way to keep DSP/BIOS 5.42 for now and still have some RTOS Analyzer functionality? If not, do you have any opinion on how big a job it might be to change from DSP/BIOS 5.42 to the current version of SYS/BIOS?

I think It's going to be important for me to have the trace functionality when debugging new code for my system.  

Fingers crossed for the first two items.

Regarding RTOS Analyzer, we dropped support for RTDX, so for DSP/BIOS 5.x applications in CCS6, there is a hole. Regarding migrating from DSP/BIOS 5.x to SYS/BIOS 6.x, it is not too bad. I'd recommend moving to the new APIs instead of trying to use the "legacy" support in SYS/BIOS 6.x. You can take a look at the instrumentation and kernel examples in TI-RTOS for C2000 to get a feel for the change. Other than the APIs changed, the major difference is there is a .cfg instead of a .tcf. Very similar concept though (i.e. used for statically configuring the kernel). We did drop PRD support in SYS/BIOS 6.x.

Todd

Todd, the PRD is the most important function I'm using in DSP/BIOS. What replaces the PRD functions in SYS/BIOS? As an alternative, if there is no replacement for PRD in the latest SYS/BIOS, is there an older version that would support PRD and still allow RTOS Analyzer functionality?

Todd, thanks for the reply. I've spent a lot of time over the weekend trying to convert from DSP/BIOS 5.42 to SYS/BIOS 6. Here is my attempt at using the xs tool for conversion of the .tcf file to a .cfg:

C:\ti\xdctools_3_31_00_24_core>xs --xp "C:\ti\bios_6_41_02_41" ti.bios.conversion -c SingenX05-3b_RTOS.cfg --pr C:\ti\xdctools_3_31_00_24_core --pn SingenX05-3b_RTOS SingenX05-3b_RTOS.tcf

Exception in thread "main" java.lang.UnsupportedClassVersionError: Bad version number in
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:621)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268)
at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)

Any ideas on what I have wrong here? I'm a bit confused by the terms "repository location" and "Platform". Here are two more questions:

1) Specifically, regarding the repository location, if I leave that option out will the tool simply put the output file in the same directory that I'm running the xs command from?

2) Regarding the Platform, is that just any name (like myPlatform, or SingenX05-3b_RTOS) that I pick or is it something more specific and limited to a list of choices like:  ti.platforms.evmDM6437 ? And if so, where do I look for choices for this? I'm using a custom board with the F2812 that's very similar to the ezDSP- F2812, except that it has no external RAM or ROM outside the 2812 IC. 

Thanks.

Kamran,
the error message is mostly likely result of the mismatch in the version of Java classes. You probably set the environment variable XDCTOOLS_JAVA_HOME to point to a specific version of JRE, but some of the Java classes loaded while executing 'xs' were built with a newer version of JRE. You should try pointing XDCTOOLS_JAVA_HOME to the newest version of JRE available on your host, and that should fix that problem. CCS 6.1 comes with Java 7 and that should be recent enough. JRE is in ccsv6/eclipse/jre directory of your CCS installation.

The term "repository location" describes a directory where you keep multiple RTSC packages. A "platform" is one such package.

1) Yes, if you don't specify a repository a current directory will be used, and the platform package will be created there.

2) Platform names do not have to be in any specific format, but some characters are special. A character '.' specifies a subdirectory level. For example, if you name your platform 'myPlatforms.myF2812', the directory 'myPlatform' will be created and in there a subdirectory 'myF2812' will be created. Also, try to avoid characters other than ASCII word characters (a to z in either case, numbers and '_'), at least initially until you can reliably run the conversion tool.  

Sasha,
I did have XDCTOOLS_JAVA_HOME pointed to C:\Program Files (x86)\Java\jre1.8.0_40, but that's Java ver 8.0.40. I did change the environment variable in the cmd window by using the DOS set command to C:\ccsv6\eclipse\jre. I also tried setting it using forward slashes versus backslashes with no difference in result. I get the exact same error. Note that both of the Java installs are at v7 or v8. I pared down the xs command statement by removing the repository location and I get the same results. Here is the latest xs command and the result to go with it.

C:\ti\xdctools_3_31_00_24_core>xs --xp "C:\ti\bios_6_41_02_41\packages" ti.bios.conversion -c SingenX05-3b_RTOS.cfg
--pn SingenX05-3b_RTOS SingenX05-3b_RTOS.tcf
Exception in thread "main" java.lang.UnsupportedClassVersionError: Bad version number in .class file
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:621)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268)
at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)

C:\ti\xdctools_3_31_00_24_core>

When I check the XDCTOOLS_JAVA_HOME environment variable using set, it gives the correct location of C:\ccsv6\eclipse\jre. Any ideas would be greatly appreciated.

Try running xs with the options --d and xdc.traceEnable='all'. This should produce a large output, but somewhere there we should be able to see which version of Java you are running and which class is causing the error.

xs --d -Dxdc.traceEnable="all" --xp ...

and then post the output.

Sasha, here's the new xs output, as you asked for:

C:\ti\xdctools_3_31_00_24_core>xs --d -Dxdc.traceEnable="all" --xp "C:\ti\bios_6_41_02_41\packages" ti.bi
os.conversion -c SingenX05-3b_RTOS.cfg --pn SingenX05-3b_RTOS SingenX05-3b_RTOS.tcf
TC - 0: TCF_create('', 0x18feb4, 0x18fefc)
TC - 0: getClassPath(0x18e950, 0x406010, 0x407d78)
TC - 0: findFile(js.jar, 0x407d78)
TC - 0: testing C:\ti\xdctools_3_31_00_24_core\js.jar ...
TC - 0: testing C:\ti\xdctools_3_31_00_24_core\packages\xdc\shelf\java\js.jar ...
TC - 0: found C:\ti\xdctools_3_31_00_24_core\packages\xdc\shelf\java\js.jar
TC - 0: findFile(config.jar, 0x407d78)
TC - 0: testing C:\ti\xdctools_3_31_00_24_core\config.jar ...
TC - 0: found C:\ti\xdctools_3_31_00_24_core\config.jar
TC - 0: findFile(antlr.jar, 0x407d78)
TC - 0: testing C:\ti\xdctools_3_31_00_24_core\antlr.jar ...
TC - 0: testing C:\ti\xdctools_3_31_00_24_core\packages\xdc\shelf\java\antlr.jar ...
TC - 0: found C:\ti\xdctools_3_31_00_24_core\packages\xdc\shelf\java\antlr.jar
TC - 0: default class path = C:\ti\xdctools_3_31_00_24_core\packages\xdc\shelf\java\js.jar;C:\ti\xdctools
_3_31_00_24_core\config.jar;C:\ti\xdctools_3_31_00_24_core\packages\xdc\shelf\java\antlr.jar;
TC - 0: findFile(jre\bin\java.exe, 0x407d78)
TC - 0: testing C:\ti\xdctools_3_31_00_24_core\jre\bin\java.exe ...
TC - 0: found C:\ti\xdctools_3_31_00_24_core\jre\bin\java.exe
TC - 0: XDCTOOLS_JAVA_HOME = null
TC - 0: findFile(jre\bin\client\jvm.dll, 0x407d78)
TC - 0: testing C:\ti\xdctools_3_31_00_24_core\jre\bin\client\jvm.dll ...
TC - 0: found C:\ti\xdctools_3_31_00_24_core\jre\bin\client\jvm.dll
TC - 0: createVM(0x29398c, C:\ti\xdctools_3_31_00_24_core\jre\bin\client\jvm.dll, 0x18fc5c)
TC - 0: JVM option[0] = -Xverify:none
TC - 0: JVM option[1] = -Dxdc.traceEnable=all
TC - 0: JVM option[2] = -DXDCPATH=C:\ti\bios_6_41_02_41\packages
TC - 0: JVM option[3] = -Dxdc.root=C:\ti\xdctools_3_31_00_24_core
TC - 0: JVM option[4] = -Djava.class.path=C:\ti\xdctools_3_31_00_24_core\packages\xdc\shelf\java\js.jar;C
:\ti\xdctools_3_31_00_24_core\config.jar;C:\ti\xdctools_3_31_00_24_core\packages\xdc\shelf\java\antlr.jar
;
TC - 0: JVM option[5] = -Dconfig.rootDir=C:\ti\xdctools_3_31_00_24_core
TC - 0: JVM option[6] = -Dconfig.gopts=
TC - 0: JVM option[7] = vfprintf
TC - 0: JVM option[8] = exit
TC - 0: JVM option[9] = abort
TC - 0: getVMCreateFxn(0x29398c, C:\ti\xdctools_3_31_00_24_core\jre\bin\client\jvm.dll)
GD - 0: GLD_create(C:\ti\xdctools_3_31_00_24_core\jre\bin\client\jvm.dll)
GD - 0: GLD_getFxn(0x6d740000, JNI_CreateJavaVM)
TC - 0: TCF_run(0x29398c, 0x7, 0x291740)
TC - 0: runJS(0x29398c, 0x7, 0x291740): config/Shell
TC - 0: Can't find class config/Shell
Exception in thread "main" java.lang.UnsupportedClassVersionError: Bad version number in .class file
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:621)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268)
at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
C:\ti\xdctools_3_31_00_24_core\xs: exit status: 7
TC - 0: TCF_delete(0x29398c)
GD - 0: GLD_delete(0x6d740000)
TC - 0: TCF_exit(): (init count = 1)

C:\ti\xdctools_3_31_00_24_core>

Thanks and I await your reply.

The output indicates that you are using JRE from XDCtools 3.31, but the version you are using with the suffix 'core' should not have JRE. Have you renamed that installation or copied JRE from somewhere?
What's the output of C:\ti\xdctools_3_31_00_24_core\jre\bin\java.exe -version?
Also, XDCTOOLS_JAVA_HOME doesn't seem to be set.

Sasha, the java version you asked for is v5. Several months ago, I may have copied that java version into C:\ti\xdctools_3_31_00_24_core to solve some problem. Regarding XDCTOOLS_JAVA_HOME, I've been keeping the same windows 7 cmd window open and when I type "set XDCTOOLS_JAVA_HOME" i get the reply as follows:

C:\ti\xdctools_3_31_00_24_core>set XDCTOOLS_JAVA_HOME
XDCTOOLS_JAVA_HOME = c:/ccsv6/eclipse/jre

So, unless I need to set it elsewhere, like in the project build settings, it seems to be set properly.

Can I fix it by deleting the jre in C:\ti\xdctools_3_31_00_24_core that shouldn't be there? Also, where should I set the XDCTOOLS_JAVA_HOME env var if not in the dos command window I'm using to run xs.exe?

Thanks.

Definitely delete jre form XDCtools 3.31. As for XDCTOOLS_JAVA_HOME, I am not sure why it's not being read properly. I have that environment variable set in System settings, in Control Panel->System->Advanced System Settings->Advanced->Environment Variables. You may want to try that too, and then run the xs command again.

Sasha, XDCTOOLS_JAVA_HOME is already (and has been) set in Control Panel->System->Advanced System Settings->Advanced->Environment Variables to C:\ccsv6\eclipse\jre. I'll delete the jre and try again. Do I need to reboot win 7 in between?

Here's the latest xs console output from the dos command window, it looks better, but there still seems to be a problem:

C:\ti\xdctools_3_31_00_24_core>xs --d -Dxdc.traceEnable="all" --xp "C:\ti\bios_6_41_02_41\packages" ti.bi
os.conversion -c SingenX05-3b_RTOS.cfg --pn SingenX05-3b_RTOS SingenX05-3b_RTOS.tcf
TC - 0: TCF_create('', 0x18feb4, 0x18fefc)
TC - 0: getClassPath(0x18e950, 0x406010, 0x407d78)
TC - 0: findFile(js.jar, 0x407d78)
TC - 0: testing C:\ti\xdctools_3_31_00_24_core\js.jar ...
TC - 0: testing C:\ti\xdctools_3_31_00_24_core\packages\xdc\shelf\java\js.jar ...
TC - 0: found C:\ti\xdctools_3_31_00_24_core\packages\xdc\shelf\java\js.jar
TC - 0: findFile(config.jar, 0x407d78)
TC - 0: testing C:\ti\xdctools_3_31_00_24_core\config.jar ...
TC - 0: found C:\ti\xdctools_3_31_00_24_core\config.jar
TC - 0: findFile(antlr.jar, 0x407d78)
TC - 0: testing C:\ti\xdctools_3_31_00_24_core\antlr.jar ...
TC - 0: testing C:\ti\xdctools_3_31_00_24_core\packages\xdc\shelf\java\antlr.jar ...
TC - 0: found C:\ti\xdctools_3_31_00_24_core\packages\xdc\shelf\java\antlr.jar
TC - 0: default class path = C:\ti\xdctools_3_31_00_24_core\packages\xdc\shelf\java\js.jar;C:\ti\xdctools
_3_31_00_24_core\config.jar;C:\ti\xdctools_3_31_00_24_core\packages\xdc\shelf\java\antlr.jar;
TC - 0: findFile(jre\bin\java.exe, 0x407d78)
TC - 0: testing C:\ti\xdctools_3_31_00_24_core\jre\bin\java.exe ...
TC - 0: testing C:\ti\xdctools_3_31_00_24_core\packages\xdc\shelf\java\jre\bin\java.exe ...
TC - 0: file 'jre\bin\java.exe' not found.
TC - 0: findFile(jre\bin\java, 0x407d78)
TC - 0: testing C:\ti\xdctools_3_31_00_24_core\jre\bin\java ...
TC - 0: testing C:\ti\xdctools_3_31_00_24_core\packages\xdc\shelf\java\jre\bin\java ...
TC - 0: file 'jre\bin\java' not found.
TC - 0: findFile(bin\java.exe, 0x407d78)
TC - 0: testing C:\ti\xdctools_3_31_00_24_core\bin\java.exe ...
TC - 0: testing C:\ti\xdctools_3_31_00_24_core\packages\xdc\shelf\java\bin\java.exe ...
TC - 0: file 'bin\java.exe' not found.
TC - 0: findFile(bin\java, 0x407d78)
TC - 0: testing C:\ti\xdctools_3_31_00_24_core\bin\java ...
TC - 0: testing C:\ti\xdctools_3_31_00_24_core\packages\xdc\shelf\java\bin\java ...
TC - 0: file 'bin\java' not found.
TC - 0: XDCTOOLS_JAVA_HOME = C:\ti\ccsv6\eclipse\jre
TC - 0: findFile(jre\bin\client\jvm.dll, 0x407d78)
TC - 0: testing C:\ti\xdctools_3_31_00_24_core\jre\bin\client\jvm.dll ...
TC - 0: testing C:\ti\xdctools_3_31_00_24_core\packages\xdc\shelf\java\jre\bin\client\jvm.dll ...
TC - 0: file 'jre\bin\client\jvm.dll' not found.
TC - 0: testing C:\ti\ccsv6\eclipse\jre\jre\bin\client\jvm.dll ...
TC - 0: findFile(bin\client\jvm.dll, 0x407d78)
TC - 0: testing C:\ti\xdctools_3_31_00_24_core\bin\client\jvm.dll ...
TC - 0: testing C:\ti\xdctools_3_31_00_24_core\packages\xdc\shelf\java\bin\client\jvm.dll ...
TC - 0: file 'bin\client\jvm.dll' not found.
TC - 0: testing C:\ti\ccsv6\eclipse\jre\bin\client\jvm.dll ...
TC - 0: found C:\ti\ccsv6\eclipse\jre\bin\client\jvm.dll
TC - 0: createVM(0x64394c, C:\ti\ccsv6\eclipse\jre\bin\client\jvm.dll, 0x18fc5c)
TC - 0: JVM option[0] = -Xverify:none
TC - 0: JVM option[1] = -Dxdc.traceEnable=all
TC - 0: JVM option[2] = -DXDCPATH=C:\ti\bios_6_41_02_41\packages
TC - 0: JVM option[3] = -Dxdc.root=C:\ti\xdctools_3_31_00_24_core
TC - 0: JVM option[4] = -Djava.class.path=C:\ti\xdctools_3_31_00_24_core\packages\xdc\shelf\java\js.jar;C
:\ti\xdctools_3_31_00_24_core\config.jar;C:\ti\xdctools_3_31_00_24_core\packages\xdc\shelf\java\antlr.jar
;
TC - 0: JVM option[5] = -Dconfig.rootDir=C:\ti\xdctools_3_31_00_24_core
TC - 0: JVM option[6] = -Dconfig.gopts=
TC - 0: JVM option[7] = vfprintf
TC - 0: JVM option[8] = exit
TC - 0: JVM option[9] = abort
TC - 0: getVMCreateFxn(0x64394c, C:\ti\ccsv6\eclipse\jre\bin\client\jvm.dll)
GD - 0: GLD_create(C:\ti\ccsv6\eclipse\jre\bin\client\jvm.dll)
GD - 0: GLD_getFxn(0x61580000, JNI_CreateJavaVM)
TC - 0: TCF_run(0x64394c, 0x7, 0x6425b8)
TC - 0: runJS(0x64394c, 0x7, 0x6425b8): config/Shell
TC - 0: mkArgs(0x64394c, 7, 0x6425b8)
TC - 0: findFile(tconfini.tcf, 0x407d78)
TC - 0: testing C:\ti\xdctools_3_31_00_24_core\tconfini.tcf ...
TC - 0: found C:\ti\xdctools_3_31_00_24_core\tconfini.tcf
TC - 0: JVM arg[0] = -f
TC - 0: JVM arg[1] = C:\ti\xdctools_3_31_00_24_core\tconfini.tcf
TC - 0: JVM arg[2] = C:\ti\xdctools_3_31_00_24_core/packages/xdc/xs.js
TC - 0: JVM arg[3] = ti.bios.conversion
TC - 0: JVM arg[4] = -c
TC - 0: JVM arg[5] = SingenX05-3b_RTOS.cfg
TC - 0: JVM arg[6] = --pn
TC - 0: JVM arg[7] = SingenX05-3b_RTOS
TC - 0: JVM arg[8] = SingenX05-3b_RTOS.tcf
TIME=06:22:32.528 PM -- xdc: loadPackage: xdc shell --> xdc (no dependency) (packageLoad, all)
TIME=06:22:32.532 PM -- xdc: loadPackage: xdc shell --> ti.bios.conversion (packageLoad, all)
TIME=06:22:32.540 PM -- xdc: loadPackage: ti.bios.conversion loaded from C:/ti/bios_6_41_02_41/packages/
(packageLoad, all)
TIME=06:22:32.554 PM -- xdc: loadPackage: ti.bios.conversion --> xdc (packageLoad, all)
TIME=06:22:32.558 PM -- xdc: loadPackage: ti.bios.conversion --> xdc.corevers (packageLoad, all)
TIME=06:22:32.566 PM -- xdc: loadPackage: ti.bios.conversion --> xdc.tools (packageLoad, all)
TIME=06:22:32.573 PM -- xdc: loadPackage: xdc.tools loaded from C:/ti/xdctools_3_31_00_24_core/packages/
(packageLoad, all)
TIME=06:22:32.587 PM -- xdc: loadPackage: xdc.tools --> xdc (packageLoad, all)
TIME=06:22:32.592 PM -- xdc: loadPackage: xdc.tools --> xdc.corevers (packageLoad, all)
TIME=06:22:32.654 PM -- xdc: loadPackage: xdc shell --> xdc.tools (no dependency) (packageLoad, all)
TypeError: Cannot call property oldLoadPlat in object [object Object]. It is not a function, it is "undefined".
js: "./packages/xdc/tools/Cmdr.xs", line 51: Error: ti.bios.conversion: ReferenceError: "prog" is not defined.
"C:/ti/bios_6_41_02_41/packages/ti/bios/conversion/Main.xs", line 91
"./packages/xdc/tools/ICmd.xs", line 50
"./packages/xdc/xs.js", line 188
TC - 0: returned from config/Shell.main (status = 1)
C:\ti\xdctools_3_31_00_24_core\xs: exit status: 1
TC - 0: TCF_delete(0x64394c)
GD - 0: GLD_delete(0x61580000)
TC - 0: TCF_exit(): (init count = 1)

C:\ti\xdctools_3_31_00_24_core>

These two lines from above are the error lines:
TypeError: Cannot call property oldLoadPlat in object [object Object]. It is not a function, it is "undefined".
js: "./packages/xdc/tools/Cmdr.xs", line 51: Error: ti.bios.conversion: ReferenceError: "prog" is not defined.

I'm lost on this. But at least it seems to be using the correct java version. What do you think is wrong now?

Sasha, something else. Is it possible that I'm using an incorrect version of xdctools? The SYS/BIOS Product Download Pages say that SYS/BIOS v6.41.02.41 is recommended to be used with XDCTOOLS v3.30.06.67 and I'm using v3.31_00_24_core.