Running compiler validation suite programs from the command line

Olwen,

This is even a bit more complex with the Hercules devices because the compiler is a generic ARM compiler and doesn't include the necessary device initialization code in the runtime library. And with all of the diagnostics on this device quite some initialization code is required.

HalCoGen is the tool to generate the device initialization code, starting from the interrupt vector c_int00.

HalCoGen will generate everything you need to get to main() where you could actually try running a simple 'Hello World' and have success.

If you try the classic "Hello World" with the C compiler/CCS alone - you'll just get stuck at an exception due to the core compare firing as you need to take special steps to sync up the cores. If you got past that error you'd hit another and another... So avoid this by using HalCoGen to
generate the startup code.

For an example of building and running through an automated flow you can look at
www.mathworks.com/.../46332-ti-hercules-pil-target-for-rm48

This includes a framework consisting of HalCoGen code that gets you to main() and it uses DSS scripting with a customized version of 'loadti' (example from DSS) to download and run a program into the target. In this case it disconnects from the target after download/running and then uses the serial port to communicate with simulink. If you redirect your console IO to the serial port you can probably do the same with your compiler validation.

Anthony,

Sorry that my previous email went direct to you. I meant to send it via the forum. Put it down to a combination of addle-headedness plus keyboard-and-finger trouble at this end - mea culpa :-)

OK - I've now got the DSS stuff from the Mathworks link you sent me and have read through the .js scripts to get an idea of what they are doing and how they are doing it. So far, so good.

Other vendors' compilers with which I am familiar have all used the gdb protocol either via direct connection to the dev board or via a Segger or clone-of-a-Segger JTAG connector module. Their equivalents of loadti are also somewhat more encapsulated than loadti. Indeed for one compiler that I tested, the load-and-run arrangements were so well encapsulated that it needed only 80 lines or so of Tcl script to automate the entire process - thus avoiding the need to use even the driver program supplied with the test suite. It's all feels a bit more "bare-bones" with the current TI DSS facilities. The combination of Perennial's test driver and loadti makes this by far the most fiddly validation I've ever done. IMHO TI could do itself a favour by trying to make command-line test running as smooth as it is using, say, an IAR compiler.

To be honest, I'm a bit surprised that javascript was chosen to automate the DSS facility. Tcl would have been my first choice, mainly because it was designed precisely for glueware jobs (which is essentially what loadti is doing) but also because the bad parts of javascript as a scripting language really put me off it for use in critical testing. As the woes of scripting languages go, Tcl's are by far the mildest owing to it's very simple language concept.

AFAI can see, I'll have to set up the Perennial CVSA-F DRIVER program to invoke loadti to load and run the program on the target. Done that way, the I can compile the SCAFFOLD.C program that is linked into each test program so that test IO uses <stdio.h> on-target. This will make it possible to configure the Perennial DRIVER as if for a hosted program that uses <stdio.h> on-host. (So much for the theory.)

I can't see any obvious technical beartraps with this approach, except that I reckon I might have a lot of trial and error getting all the various configuration arguments right. Once I'm farther along with the process, I'll probably have one or two more focussed postings as regards nuts-and-bolts details.


Thanks for your help so far.

Regards,
Olwen

Thanks Olwen for the update.
Are there open questions on this thread?

As an FYI - there is a GDB Server front-end to DSS available here: processors.wiki.ti.com/.../XDS_GDB_Agent
which you can try if you are more comfortable with GDB.

Anthony,

We'll use DDS rather than gdb to make it as close as possible close to the normal TI CCS development approach.

Thinking of previous validations with tools that use gdb, I think that since gdb has been in use for some time, compiler vendors that use it have had time enough to make program loading running and results-capture (a) easy to configure and (b) cleanly encapsulated. No disrespect to TI but the loadti script that comes with CCSv6 has the feel of beta software. You really need some means of automating or else machine-assisting the task of configuration related to its use.

From a compiler tester's viewpoint, the use of environment variables is deprecated because they provide elements of configuration data that are not captured as persistent data by the scripts that use them. As far as possible in what I'm currently doing, we ensure that configuration data and options are written in command files. Also, since running a compiler test is mostly a once-off task, there is no need to build in the flexibility to put things in any directory you want. A fixed directory structure is actually better if you want to make testing repeatable and reproducible.

As I've just put in my weekly report to my manager, this particular combination of compiler, IDE package and test suite happens to require a lot more configuration than with other compilers that I've tested. One thing that would be helpful is if TI were to provide with CCSv6 the same loadti scripts that are used in the compiler qualification kit. That would make things a great deal easier for testers working on projects that need do to compiler validations on-target and under the compiler options used to develop the production embedded code.

After having read the .js scripts used by loadti, I have a clearer picture of where they fit into what I'm trying to do. I expect that most questions from here on will be about nitty-grittty configuration parameters.

Thank for your help so far.

Kind regards,
Olwen

Olwen,

You might want to see  as well.

For specific questions about compiler validation - please post to the compiler forum

Best Regards,

Anthony

Well, this question arises in my compiler validation but is actually about getting DSS to work. For the moment I'm *still* trying to get a simple Hello World program to run on the target. For the best part of the last three weeks I've been *fighting all day every day with configuration issues* surrounding the use of DSS.

Now I can get to a point in my load script where I try the following:

var debugSession = debugServer.openSession( <boardname>, <cpuname> )

The problem is that nowhere can I find any documentation that tells me what values to use for <boardname> and <cpuname>. I'm connected to a Hercules HDK board on which the CPU bears the number RM48L952ZWTT. Can anyone tell me values I should use for the <boardname> and <cpuname> parameters - or should I, in the absence of better documentation, simply continue by blind trial and error?

Olwen

Continuing by blind trial and error, I have found that using "Texas Instruments XDS100v2 USB Debug Probe_0/CortexR4" as the single argument to openSession, my load script now actually attempts to load something to the target ...

... which rapidly brought me to the next hurdle:

While attempting a load to the target dev board I get the error messages:

>CortexR4: GEL Output: Memory Map Setup for Flash at Address 0x0

>CortexR4: GEL Output: Memory Map Setup for Flash at Address 0x0 due to System Reset

>CortexR4: GEL Output: Memory Map Setup for Flash at Address 0x0 due to System Reset

whereafter everything hangs.


What do I do now?


Olwen

PS: Is anyone actually looking at these posts ?

Olwen,

Did you try the customized loadti script in the matlab pil package? The only reason I suggest this over the stock file is that I had to override a particular default setting which was halting the processor on a disconnect (rather than letting it run freely).

Otherwise I would even point you to the stock example.

There is documentation for Debug Server Scripting but is' mainly between wiki and online help rather than a PDF book.

For support on DSS - the CCS forum is the right place. Here we know about the silicon and enough about the tools to get over common issues but if you are digging into the internals of the 'loadti' example you need an Guru like Ki-Soo e2e.ti.com/.../1043327 to help you... Post on the CCS forum for that ..

The messages you listed about the flash at address 0 this is a normal message from the GEL file in one of the callbacks like 'OnTargetConnect()' or something.. I'd need to look at the Gel to tell you exactly. But it is normal not an error. You always get this.
The GEL file that is loaded is embedded in the .CCXML file - so you can look at that file to find which GEL you are using and then look at the GEL to find out which step emits that message.

But the point is it's normal not an error. I don't see an 'error' so the hang may be not really a hang so much but a 'there's nothing more to do' kind of state that you are in..

Anthony,

After I posted I found that it does not hang but produces not output for an hour or so and then coughs out more messages, of which I have a screen-snip capture.

I'll shoft to the CCS forum as you suggest.

regards,
Olwen