TASKING TriCore-PCP VX-toolset v2.5r1
RELEASE NOTE
SUMMARY
This release note describes the changes and new features of all TASKING TriCore products
since v2.4r1.
The following parts are described:
The solved and known problems are not part of this release note, they are described in
solved_2_5r1.html, which is delivered with the product.
The main reason for this release is:
- Introduction of the PCP C Compiler
With this release TASKING introduces a C compiler for TriCore's Peripheral Control Processor.
Depending on your software license, this PCP C compiler is bundled with the product or not.
If you purchased one of the (existing) products:
07-200-160-012, 07-200-160-024 or 07-200-160-044, the PCP C compiler is not part of the toolchain.
However, you may note that the directory structure has slightly changed to accommodate the new
compiler.
The default installation directory now is TriCore v2.5r1 and the ctc subdirectory
contains the TriCore compiler. If the product contains a PCP C compiler as well, it can be
found in the cpcp subdirectory.
New product 07-200-160-025 contains the combination of a traditional TriCore VX-toolset and
additionally a PCP C compiler product. With the PCP C compiler product one can build
PCP relocatable output files.
These output files are then to be linked against TriCore code build with the traditional
TASKING TriCore VX-toolset. How to build an absolute elf file using both toolsets is shown
in the PCP examples. The manuals for the PCP C compiler can be found in the doc directory
of the PCP C compiler product.
The PCP C compiler is an ISO C99 standard C compiler for the PCP architecture, based on
TASKING's Viper technology. However it should be kept in mind that the PCP has a restricted
architecture with only a few registers available. In order to be able to create a
compiler for this restricted architecture, it is required to define a set of limitations.
Limitations and Restrictions
- The compiler supports full context mode only, since it need
all available registers for code generation.
- Channels are not interrupt-able to save on generated code.
- A static stack is used to save on generated code, however a static stack does not
allow recursion.
- No stack parameter passing for indirect function calls, since the number of
parameters is restricted.
- No support for the copy instruction, since this instruction would require 2 or 3
registers and the compiler need all available registers.
- No romdata available, constant data must be copied to PRAM at (TriCore) startup time.
- According to the ISO C99 standard, data type "long long" needs to be at least
64 bits wide. However, in the PCP compiler all data types are 32 bits wide.
- For safety integrity reasons the PCP may not address the FPI bus. Intrinsics
__ld32_fpi() and __st32_fpi() are available for accessing SFRs via the FPI bus.
- In order to allow re-arbitration of interrupts a "voluntary exiting" scheme is
supported via the intrinsic __exit().
- Limited debug capabilities available for PCP.
- No EDE integration.This will be considered for a next release.
With the TASKING TriCore-PCP VX-toolset one first need to build a PCP relocatable output file.
This relocatable output file can be created by using the control program in the
cpcp\bin directory.
To prevent the linker to start the locate phase you need to specify an additional
option -cl. The invocation to create a relocatable PCP output file therefore is:
$(ROOTDIR)\cpcp\bin\ccpcp -cl <pcp_options> <pcp_sources> -o <pcp_output>
The PCP output file next needs to be linked against TriCore code build with the regular
TASKING TriCore VX-toolset as found in the ctc directory.
The invocation of the control program is as follows:
$(ROOTDIR)\ctc\bin\cctc <pcp_output> <tc_options> <tc_sources> -o <combined_output>
This way an absolute elf file is created, containing both the TriCore and the PCP code.
Since there is no EDE support for the PCP C compiler yet, this build process is not automated.
Features
The TriCore simulator that comes with the product simulates the Peripheral
Control Processor, by starting a PCP plugin simulator.
CrossView allows you to set up breakpoints in both TriCore and PCP code. Once a
breakpoint is hit, the program stops and a blue marker indicates the current Program
Counter. From here you can single step through the code. On each single step, the
simulator steps both the TriCore and the PCP code. You can select which code
- TriCore or PCP - should get the focus while single stepping,
by making the proper selection in the "Target | mode" menu.
The general purpose PCP registers can be watched from a register window, by selecting
PCP_RO through PCP_R7 in the "View | Register" menu.
Limitations
Currently CrossView can not show a stack trace for PCP code. The PCP tools create a static
stack, and CrossView can not retrieve the return addresses if no stack or frame pointer
is available. DWARF Debugging Information Format v3.0 enables to retrieve this kind of
information, but this will be introduced in a subsequent version of the tool.
All stack related features, such as stack breakpoints and return from function won't work
as well for the same reason.
Furthermore the debug capabilities as described above are available for the simulator only.
Hardware support is considered in a later stage.
To simulate the Peripheral Control Processor, the standard TriCore Instruction Set
Simulator (tsim) starts a PCP plugin simulator (pcp). This is set up in a configuration
file named DConfig that is located in the etc directory. This file tells the TriCore
ISS to start up the PCP plugin with the specified options.
The available command line options for the PCP plugin simulator are:
| Option | Argument | Description | Default |
|---|
| cmem_base | address | Code memory address configuration | 0xf0060000 |
| cmem_size | size | Code memory size configuration | 0x7fff |
| pram_base | address | Parameter memory address configuration | 0xf0050000 |
| pram_size | size | Parameter memory size configuration | 0x3fff |
| preg_base | address | Pcp register memory address configuration | 0xf0043f00 |
| preg_size | size | Pcp register memory size configuration | 0xcc |
| psrn_base | address | Pcp service register node memory address configuration | 0xf0043fd0 |
| psrn_size | size | Pcp service register node memory size configuration | 0x2f |
If a non default derivative is used, it might be necessary to change the options in this file.
The default derivative for the simulator is the tc1920b.
In order to build the examples for derivatives without external memory,
there is a workaround to prevent error messages within the linking phase.
For all derivatives without external memory (TC116X, TC1762, TC1764 and TC1766)
you need to make the following adjustment:
EDE users
Go to menu "Project | Project Options..." and go to the page "Linker
| Script File | Internal Memory". On this page change the SPRAM
in such a way that the column "Alloc" gets the value ON
and the column "Type" gets the value ROM.
Command line users
Open your own project LSL file or open the included "<derivative_name>.lsl"
file (present in the include.lsl subdirectory of the product). Adjust
the type of the SPRAM into ROM:
memory spram
{
...
type = rom;
...
}
In previous versions of the toolchain the library sources were extracted during the
installation process and were available in the lib\src, lib\src.cpp and
lib\src.stl directories. As from this version on,
the library sources are packed in an archive. In the case you want to refer to the library
sources and provided that you have a valid license key, you can extract the archive.
To extract for instance the C library sources, go to the lib\src directory and
run the local tool "install-lib-sources". Note that
in the case you are evaluating the product as trial version, you will not be allowed to
extract the sources.
Copyright 2007 Altium BV