portugalfuturista/universalisos
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

feat(docs): extract RVS PDF manuals and regenerate index

Browse source 
- Extract 28 non-empty RVS PDFs from src/scov/RVS/ to docs-extracted/
- Preserve full source tree structure under docs-extracted/src/scov/RVS/
- Regenerate docs-extracted/index.md to include all 65 extracted documents
- List 21 empty PDFs that could not be extracted
This commit is contained in:
Fábio Coutada 2026-07-06 23:16:33 +01:00
parent 0d101203e4
commit ebcfde0f5e
29 changed files with 38947 additions and 43 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

127
docs-extracted/index.md
View file

@ -1,62 +1,103 @@
--- ---
title: "PikeOS Documentation Extract Index" title: "PikeOS Documentation Extract Index"
generated: "2026-07-06T23:06:49.724638" generated: "2026-07-06T23:16:13.532186"
--- ---
# PikeOS Documentation Extract Index # PikeOS Documentation Extract Index
This index lists all 37 PikeOS PDF manuals that were successfully extracted to markdown. This index lists all 65 PikeOS PDF manuals that were successfully extracted to markdown.
Eight PDFs were empty (0 bytes) and could not be extracted; they are listed at the end. Empty (0-byte) PDFs could not be extracted and are listed at the end.
| Document | Category | Source PDF | | Document | Category | Source PDF |
|----------|----------|------------| |----------|----------|------------|
| [As User Manual](cdk/as-user-manual.md) | cdk | `docs/cdk/as-user-manual.pdf` | | [As User Manual](cdk/as-user-manual.md) | `cdk` | `docs/cdk/as-user-manual.pdf` |
| [Binutils User Manual](cdk/binutils-user-manual.md) | cdk | `docs/cdk/binutils-user-manual.pdf` | | [Binutils User Manual](cdk/binutils-user-manual.md) | `cdk` | `docs/cdk/binutils-user-manual.pdf` |
| [Cpp Preprocessor User Manual](cdk/cpp-preprocessor-user-manual.md) | cdk | `docs/cdk/cpp-preprocessor-user-manual.pdf` | | [Cpp Preprocessor User Manual](cdk/cpp-preprocessor-user-manual.md) | `cdk` | `docs/cdk/cpp-preprocessor-user-manual.pdf` |
| [Cpplib Internals](cdk/cpplib-internals.md) | cdk | `docs/cdk/cpplib-internals.pdf` | | [Cpplib Internals](cdk/cpplib-internals.md) | `cdk` | `docs/cdk/cpplib-internals.pdf` |
| [Gcc Installation Manual](cdk/gcc-installation-manual.md) | cdk | `docs/cdk/gcc-installation-manual.pdf` | | [Gcc Installation Manual](cdk/gcc-installation-manual.md) | `cdk` | `docs/cdk/gcc-installation-manual.pdf` |
| [Ld User Manual](cdk/ld-user-manual.md) | cdk | `docs/cdk/ld-user-manual.pdf` | | [Ld User Manual](cdk/ld-user-manual.md) | `cdk` | `docs/cdk/ld-user-manual.pdf` |
| [Anis Reference Manual](development/anis-reference-manual.md) | development | `docs/development/anis-reference-manual.pdf` | | [Anis Reference Manual](development/anis-reference-manual.md) | `development` | `docs/development/anis-reference-manual.pdf` |
| [Cfs Reference Manual](development/cfs-reference-manual.md) | development | `docs/development/cfs-reference-manual.pdf` | | [Cfs Reference Manual](development/cfs-reference-manual.md) | `development` | `docs/development/cfs-reference-manual.pdf` |
| [Instrumentation Monitoring Reference Manual](development/instrumentation-monitoring-reference-manual.md) | development | `docs/development/instrumentation-monitoring-reference-manual.pdf` | | [Instrumentation Monitoring Reference Manual](development/instrumentation-monitoring-reference-manual.md) | `development` | `docs/development/instrumentation-monitoring-reference-manual.pdf` |
| [Kernel Reference Manual](development/kernel-reference-manual.md) | development | `docs/development/kernel-reference-manual.pdf` | | [Kernel Reference Manual](development/kernel-reference-manual.md) | `development` | `docs/development/kernel-reference-manual.pdf` |
| [Libstand Reference Manual](development/libstand-reference-manual.md) | development | `docs/development/libstand-reference-manual.pdf` | | [Libstand Reference Manual](development/libstand-reference-manual.md) | `development` | `docs/development/libstand-reference-manual.pdf` |
| [Psp Development Guide](development/psp-development-guide.md) | development | `docs/development/psp-development-guide.pdf` | | [Psp Development Guide](development/psp-development-guide.md) | `development` | `docs/development/psp-development-guide.pdf` |
| [Pssw Reference Manual](development/pssw-reference-manual.md) | development | `docs/development/pssw-reference-manual.pdf` | | [Pssw Reference Manual](development/pssw-reference-manual.md) | `development` | `docs/development/pssw-reference-manual.pdf` |
| [Test Framework Reference Manual](development/test-framework-reference-manual.md) | development | `docs/development/test-framework-reference-manual.pdf` | | [Test Framework Reference Manual](development/test-framework-reference-manual.md) | `development` | `docs/development/test-framework-reference-manual.pdf` |
| [Volume Provider Reference Manual](development/volume-provider-reference-manual.md) | development | `docs/development/volume-provider-reference-manual.pdf` | | [Volume Provider Reference Manual](development/volume-provider-reference-manual.md) | `development` | `docs/development/volume-provider-reference-manual.pdf` |
| [Hardware Virtualization](hardware-virtualization/hardware-virtualization.md) | hardware-virtualization | `docs/hardware-virtualization/hardware-virtualization.pdf` | | [Hardware Virtualization](hardware-virtualization/hardware-virtualization.md) | `hardware-virtualization` | `docs/hardware-virtualization/hardware-virtualization.pdf` |
| [Pikeos Installation Guide](pikeos-installation-guide.md) | general | `docs/pikeos-installation-guide.pdf` | | [Pikeos Installation Guide](pikeos-installation-guide.md) | `general` | `docs/pikeos-installation-guide.pdf` |
| [Pikeos C Programming Environment](pikeos-native/pikeos-c-programming-environment.md) | pikeos-native | `docs/pikeos-native/pikeos-c-programming-environment.pdf` | | [Pikeos C Programming Environment](pikeos-native/pikeos-c-programming-environment.md) | `pikeos-native` | `docs/pikeos-native/pikeos-c-programming-environment.pdf` |
| [Pikeos Cxx Programming Environment](pikeos-native/pikeos-cxx-programming-environment.md) | pikeos-native | `docs/pikeos-native/pikeos-cxx-programming-environment.pdf` | | [Pikeos Cxx Programming Environment](pikeos-native/pikeos-cxx-programming-environment.md) | `pikeos-native` | `docs/pikeos-native/pikeos-cxx-programming-environment.pdf` |
| [Pikeos Native Api Extensions](pikeos-native/pikeos-native-api-extensions.md) | pikeos-native | `docs/pikeos-native/pikeos-native-api-extensions.pdf` | | [Pikeos Native Api Extensions](pikeos-native/pikeos-native-api-extensions.md) | `pikeos-native` | `docs/pikeos-native/pikeos-native-api-extensions.pdf` |
| [Platform Manual Arm](platform/platform-manual-ARM.md) | platform | `docs/platform/platform-manual-ARM.pdf` | | [Platform Manual Arm](platform/platform-manual-ARM.md) | `platform` | `docs/platform/platform-manual-ARM.pdf` |
| [Platform Manual Arm 64Bit](platform/platform-manual-ARM_64bit.md) | platform | `docs/platform/platform-manual-ARM_64bit.pdf` | | [Platform Manual Arm 64Bit](platform/platform-manual-ARM_64bit.md) | `platform` | `docs/platform/platform-manual-ARM_64bit.pdf` |
| [Platform Manual Ppc E500](platform/platform-manual-PPC_e500.md) | platform | `docs/platform/platform-manual-PPC_e500.pdf` | | [Platform Manual Ppc E500](platform/platform-manual-PPC_e500.md) | `platform` | `docs/platform/platform-manual-PPC_e500.pdf` |
| [Platform Manual Ppc E500Mc 4G](platform/platform-manual-PPC_e500mc-4g.md) | platform | `docs/platform/platform-manual-PPC_e500mc-4g.pdf` | | [Platform Manual Ppc E500Mc 4G](platform/platform-manual-PPC_e500mc-4g.md) | `platform` | `docs/platform/platform-manual-PPC_e500mc-4g.pdf` |
| [Platform Manual Ppc E500Mc](platform/platform-manual-PPC_e500mc.md) | platform | `docs/platform/platform-manual-PPC_e500mc.pdf` | | [Platform Manual Ppc E500Mc](platform/platform-manual-PPC_e500mc.md) | `platform` | `docs/platform/platform-manual-PPC_e500mc.pdf` |
| [Platform Manual Ppc E5500](platform/platform-manual-PPC_e5500.md) | platform | `docs/platform/platform-manual-PPC_e5500.pdf` | | [Platform Manual Ppc E5500](platform/platform-manual-PPC_e5500.md) | `platform` | `docs/platform/platform-manual-PPC_e5500.pdf` |
| [Platform Manual X86 Amd64](platform/platform-manual-x86_amd64.md) | platform | `docs/platform/platform-manual-x86_amd64.pdf` | | [Platform Manual X86 Amd64](platform/platform-manual-x86_amd64.md) | `platform` | `docs/platform/platform-manual-x86_amd64.pdf` |
| [Posix Conformance](posix/posix-conformance.md) | posix | `docs/posix/posix-conformance.pdf` | | [Posix Conformance](posix/posix-conformance.md) | `posix` | `docs/posix/posix-conformance.pdf` |
| [Posix Cxx](posix/posix-cxx.md) | posix | `docs/posix/posix-cxx.pdf` | | [Posix Cxx](posix/posix-cxx.md) | `posix` | `docs/posix/posix-cxx.pdf` |
| [Posix Lwip](posix/posix-lwip.md) | posix | `docs/posix/posix-lwip.pdf` | | [Posix Lwip](posix/posix-lwip.md) | `posix` | `docs/posix/posix-lwip.pdf` |
| [Releasenotes Anis 5.0.3](releasenotes/releasenotes-anis-5.0.3.md) | releasenotes | `docs/releasenotes/releasenotes-anis-5.0.3.pdf` | | [Releasenotes Anis 5.0.3](releasenotes/releasenotes-anis-5.0.3.md) | `releasenotes` | `docs/releasenotes/releasenotes-anis-5.0.3.pdf` |
| [Releasenotes Apex 5.0.3](releasenotes/releasenotes-apex-5.0.3.md) | releasenotes | `docs/releasenotes/releasenotes-apex-5.0.3.pdf` | | [Releasenotes Apex 5.0.3](releasenotes/releasenotes-apex-5.0.3.md) | `releasenotes` | `docs/releasenotes/releasenotes-apex-5.0.3.pdf` |
| [Releasenotes Bsp 5.0.3](releasenotes/releasenotes-bsp-5.0.3.md) | releasenotes | `docs/releasenotes/releasenotes-bsp-5.0.3.pdf` | | [Releasenotes Bsp 5.0.3](releasenotes/releasenotes-bsp-5.0.3.md) | `releasenotes` | `docs/releasenotes/releasenotes-bsp-5.0.3.pdf` |
| [Releasenotes Cfs 5.0.3](releasenotes/releasenotes-cfs-5.0.3.md) | releasenotes | `docs/releasenotes/releasenotes-cfs-5.0.3.pdf` | | [Releasenotes Cfs 5.0.3](releasenotes/releasenotes-cfs-5.0.3.md) | `releasenotes` | `docs/releasenotes/releasenotes-cfs-5.0.3.pdf` |
| [Releasenotes Hwvirt 5.0.3](releasenotes/releasenotes-hwvirt-5.0.3.md) | releasenotes | `docs/releasenotes/releasenotes-hwvirt-5.0.3.pdf` | | [Releasenotes Hwvirt 5.0.3](releasenotes/releasenotes-hwvirt-5.0.3.md) | `releasenotes` | `docs/releasenotes/releasenotes-hwvirt-5.0.3.pdf` |
| [Releasenotes Pikeos 5.0.3](releasenotes/releasenotes-pikeos-5.0.3.md) | releasenotes | `docs/releasenotes/releasenotes-pikeos-5.0.3.pdf` | | [Releasenotes Pikeos 5.0.3](releasenotes/releasenotes-pikeos-5.0.3.md) | `releasenotes` | `docs/releasenotes/releasenotes-pikeos-5.0.3.pdf` |
| [Releasenotes Posix 5.0.3](releasenotes/releasenotes-posix-5.0.3.md) | releasenotes | `docs/releasenotes/releasenotes-posix-5.0.3.pdf` | | [Releasenotes Posix 5.0.3](releasenotes/releasenotes-posix-5.0.3.md) | `releasenotes` | `docs/releasenotes/releasenotes-posix-5.0.3.pdf` |
| [Rapitask User Guide](src/scov/RVS/auxd/rapitaskviewer/RapiTask_User_Guide.md) | `src/scov/RVS/auxd/rapitaskviewer` | `./src/scov/RVS/auxd/rapitaskviewer/RapiTask_User_Guide.pdf` |
| [Installation And Licensing Guide](src/scov/RVS/doc/Installation_and_Licensing_Guide.md) | `src/scov/RVS/doc` | `./src/scov/RVS/doc/Installation_and_Licensing_Guide.pdf` |
| [Integration Guide](src/scov/RVS/doc/Integration_Guide.md) | `src/scov/RVS/doc` | `./src/scov/RVS/doc/Integration_Guide.pdf` |
| [Migration Guide](src/scov/RVS/doc/Migration_Guide.md) | `src/scov/RVS/doc` | `./src/scov/RVS/doc/Migration_Guide.pdf` |
| [Rapitask User Guide](src/scov/RVS/doc/RapiTask/RapiTask_User_Guide.md) | `src/scov/RVS/doc/RapiTask` | `./src/scov/RVS/doc/RapiTask/RapiTask_User_Guide.pdf` |
| [Rapitest User Guide](src/scov/RVS/doc/RapiTest/RapiTest_User_Guide.md) | `src/scov/RVS/doc/RapiTest` | `./src/scov/RVS/doc/RapiTest/RapiTest_User_Guide.pdf` |
| [Spreadsheet Test Format Cheat Sheet](src/scov/RVS/doc/RapiTest/Spreadsheet_Test_Format_Cheat_Sheet.md) | `src/scov/RVS/doc/RapiTest` | `./src/scov/RVS/doc/RapiTest/Spreadsheet_Test_Format_Cheat_Sheet.pdf` |
| [Spreadsheet Test Format User Guide](src/scov/RVS/doc/RapiTest/Spreadsheet_Test_Format_User_Guide.md) | `src/scov/RVS/doc/RapiTest` | `./src/scov/RVS/doc/RapiTest/Spreadsheet_Test_Format_User_Guide.pdf` |
| [Integration Library Implementation](src/scov/RVS/doc/Reference/Integration_Library_Implementation.md) | `src/scov/RVS/doc/Reference` | `./src/scov/RVS/doc/Reference/Integration_Library_Implementation.pdf` |
| [Rvs Annotations](src/scov/RVS/doc/Reference/RVS_Annotations.md) | `src/scov/RVS/doc/Reference` | `./src/scov/RVS/doc/Reference/RVS_Annotations.pdf` |
| [Rvs Files](src/scov/RVS/doc/Reference/RVS_Files.md) | `src/scov/RVS/doc/Reference` | `./src/scov/RVS/doc/Reference/RVS_Files.pdf` |
| [Rvs Filters](src/scov/RVS/doc/Reference/RVS_Filters.md) | `src/scov/RVS/doc/Reference` | `./src/scov/RVS/doc/Reference/RVS_Filters.pdf` |
| [Troubleshooting Guide](src/scov/RVS/doc/Troubleshooting_Guide.md) | `src/scov/RVS/doc` | `./src/scov/RVS/doc/Troubleshooting_Guide.pdf` |
| [Using Rvs With Jenkins](src/scov/RVS/doc/Using_RVS_with_Jenkins.md) | `src/scov/RVS/doc` | `./src/scov/RVS/doc/Using_RVS_with_Jenkins.pdf` |
| [Rvs Ig Compilers Cl500](src/scov/RVS/integration_resources/reference/integration_annexes/Compilers/rvs-ig-compilers-cl500.md) | `src/scov/RVS/integration_resources/reference/integration_annexes/Compilers` | `./src/scov/RVS/integration_resources/reference/integration_annexes/Compilers/rvs-ig-compilers-cl500.pdf` |
| [Rvs Ig Compilers Dcc](src/scov/RVS/integration_resources/reference/integration_annexes/Compilers/rvs-ig-compilers-dcc.md) | `src/scov/RVS/integration_resources/reference/integration_annexes/Compilers` | `./src/scov/RVS/integration_resources/reference/integration_annexes/Compilers/rvs-ig-compilers-dcc.pdf` |
| [Rvs Ig Compilers Gcc](src/scov/RVS/integration_resources/reference/integration_annexes/Compilers/rvs-ig-compilers-gcc.md) | `src/scov/RVS/integration_resources/reference/integration_annexes/Compilers` | `./src/scov/RVS/integration_resources/reference/integration_annexes/Compilers/rvs-ig-compilers-gcc.pdf` |
| [Rvs Ig Compilers Ghs Multi](src/scov/RVS/integration_resources/reference/integration_annexes/Compilers/rvs-ig-compilers-ghs_multi.md) | `src/scov/RVS/integration_resources/reference/integration_annexes/Compilers` | `./src/scov/RVS/integration_resources/reference/integration_annexes/Compilers/rvs-ig-compilers-ghs_multi.pdf` |
| [Rvs Ig Compilers Tasking Classic Cc166](src/scov/RVS/integration_resources/reference/integration_annexes/Compilers/rvs-ig-compilers-tasking_classic_cc166.md) | `src/scov/RVS/integration_resources/reference/integration_annexes/Compilers` | `./src/scov/RVS/integration_resources/reference/integration_annexes/Compilers/rvs-ig-compilers-tasking_classic_cc166.pdf` |
| [Rvs Ig Compilers Tasking Vxtoolset](src/scov/RVS/integration_resources/reference/integration_annexes/Compilers/rvs-ig-compilers-tasking_vxtoolset.md) | `src/scov/RVS/integration_resources/reference/integration_annexes/Compilers` | `./src/scov/RVS/integration_resources/reference/integration_annexes/Compilers/rvs-ig-compilers-tasking_vxtoolset.pdf` |
| [Rvs Ig Visualstudio](src/scov/RVS/integration_resources/reference/integration_annexes/Compilers/rvs-ig-visualstudio.md) | `src/scov/RVS/integration_resources/reference/integration_annexes/Compilers` | `./src/scov/RVS/integration_resources/reference/integration_annexes/Compilers/rvs-ig-visualstudio.pdf` |
| [Rvs Ig Cpus Armsim](src/scov/RVS/integration_resources/reference/integration_annexes/Cpus/rvs-ig-cpus-armsim.md) | `src/scov/RVS/integration_resources/reference/integration_annexes/Cpus` | `./src/scov/RVS/integration_resources/reference/integration_annexes/Cpus/rvs-ig-cpus-armsim.pdf` |
| [Rvs Ig Cpus C166](src/scov/RVS/integration_resources/reference/integration_annexes/Cpus/rvs-ig-cpus-c166.md) | `src/scov/RVS/integration_resources/reference/integration_annexes/Cpus` | `./src/scov/RVS/integration_resources/reference/integration_annexes/Cpus/rvs-ig-cpus-c166.pdf` |
| [Rvs Ig Cpus Powerpc](src/scov/RVS/integration_resources/reference/integration_annexes/Cpus/rvs-ig-cpus-powerpc.md) | `src/scov/RVS/integration_resources/reference/integration_annexes/Cpus` | `./src/scov/RVS/integration_resources/reference/integration_annexes/Cpus/rvs-ig-cpus-powerpc.pdf` |
| [Rvs Ig Cpus St Arm Cortex](src/scov/RVS/integration_resources/reference/integration_annexes/Cpus/rvs-ig-cpus-st_arm_cortex.md) | `src/scov/RVS/integration_resources/reference/integration_annexes/Cpus` | `./src/scov/RVS/integration_resources/reference/integration_annexes/Cpus/rvs-ig-cpus-st_arm_cortex.pdf` |
| [Rvs Ig Collection Trace32](src/scov/RVS/integration_resources/reference/integration_annexes/Data Collection/rvs-ig-collection-trace32.md) | `src/scov/RVS/integration_resources/reference/integration_annexes/Data Collection` | `./src/scov/RVS/integration_resources/reference/integration_annexes/Data Collection/rvs-ig-collection-trace32.pdf` |
| [Rvs Ig Collection Vx1000](src/scov/RVS/integration_resources/reference/integration_annexes/Data Collection/rvs-ig-collection-vx1000.md) | `src/scov/RVS/integration_resources/reference/integration_annexes/Data Collection` | `./src/scov/RVS/integration_resources/reference/integration_annexes/Data Collection/rvs-ig-collection-vx1000.pdf` |
| [Rvs Ig Collection Xcp](src/scov/RVS/integration_resources/reference/integration_annexes/Data Collection/rvs-ig-collection-xcp.md) | `src/scov/RVS/integration_resources/reference/integration_annexes/Data Collection` | `./src/scov/RVS/integration_resources/reference/integration_annexes/Data Collection/rvs-ig-collection-xcp.pdf` |
## Empty PDFs (not extracted) ## Empty PDFs (not extracted)
| Source PDF | | Source PDF |
|------------| |------------|
| `docs/codeo-user-manual.pdf` |
| `docs/pikeos-tutorials.pdf` |
| `docs/pikeos-user-manual.pdf` |
| `docs/apex/apex-personality.pdf` | | `docs/apex/apex-personality.pdf` |
| `docs/cdk/gcc-internals.pdf` | | `docs/cdk/gcc-internals.pdf` |
| `docs/cdk/gcc-user-manual.pdf` | | `docs/cdk/gcc-user-manual.pdf` |
| `docs/codeo-user-manual.pdf` |
| `docs/development/driver-reference-manual.pdf` | | `docs/development/driver-reference-manual.pdf` |
| `docs/pikeos-tutorials.pdf` |
| `docs/pikeos-user-manual.pdf` |
| `docs/posix/posix-personality.pdf` | | `docs/posix/posix-personality.pdf` |
| `src/documentation/apex/apex-personality.pdf` |
| `src/documentation/cdk/gcc-internals.pdf` |
| `src/documentation/cdk/gcc-user-manual.pdf` |
| `src/documentation/codeo-user-manual.pdf` |
| `src/documentation/development/driver-reference-manual.pdf` |
| `src/documentation/pikeos-tutorials.pdf` |
| `src/documentation/pikeos-user-manual.pdf` |
| `src/documentation/posix/posix-personality.pdf` |
| `src/scov/RVS/doc/RTBx2xxx_User_Guide.pdf` |
| `src/scov/RVS/doc/RVS_User_Guide.pdf` |
| `src/scov/RVS/doc/RapiCover/RapiCover_User_Guide.pdf` |
| `src/scov/RVS/doc/RapiTime/RapiTime_User_Guide.pdf` |
| `src/scov/RVS/doc/Reference/RVS_Command_Line_Tools.pdf` |

1309
docs-extracted/src/scov/RVS/auxd/rapitaskviewer/RapiTask_User_Guide.md Normal file
View file

File diff suppressed because it is too large Load diff

1744
docs-extracted/src/scov/RVS/doc/Installation_and_Licensing_Guide.md Normal file
View file

File diff suppressed because it is too large Load diff

2702
docs-extracted/src/scov/RVS/doc/Integration_Guide.md Normal file
View file

File diff suppressed because it is too large Load diff

1506
docs-extracted/src/scov/RVS/doc/Migration_Guide.md Normal file
View file

File diff suppressed because it is too large Load diff

1309
docs-extracted/src/scov/RVS/doc/RapiTask/RapiTask_User_Guide.md Normal file
View file

File diff suppressed because it is too large Load diff

1211
docs-extracted/src/scov/RVS/doc/RapiTest/RapiTest_User_Guide.md Normal file
View file

File diff suppressed because it is too large Load diff

108
docs-extracted/src/scov/RVS/doc/RapiTest/Spreadsheet_Test_Format_Cheat_Sheet.md Normal file
View file

@ -0,0 +1,108 @@
---
title: "Spreadsheet Test Format Cheat Sheet"
source: "./src/scov/RVS/doc/RapiTest/Spreadsheet_Test_Format_Cheat_Sheet.pdf"
category: "src/scov/RVS/doc/RapiTest"
pages: 2
extracted: "2026-07-06T23:15:57.305769"
---
# Spreadsheet Test Format Cheat Sheet
> Extracted from `./src/scov/RVS/doc/RapiTest/Spreadsheet_Test_Format_Cheat_Sheet.pdf` (2 pages).
> Figures, diagrams, and tables may not render accurately in plain text.
Spreadsheet Test Format Cheat Sheet (Page 1 of 2)
Sections Function signatures Shorthands
Configuration Contains configuration options Parameter Specifies each parameter for the function Shorthand (Column) Specifies shorthand for element
Contexts Specifies contexts to search for functions @N Refers to the Nth Parameter of a function :shorthand Refers to shorthand element
specified in its declaration
Scope Specifies which results should be reported :global.obj Refers to global object obj
Type Specifies type for each parameter
Stubs Specifies signatures for stubs in test sheet (see Types and modifiers) :local.obj Refers to a Test Local object obj
Test Locals Specifies local objects for test sheet ? Match a non-overloaded function without :original Refers to the original version of a stubbed
specifying both Type and Parameters function
Tests Defines test sequences for test sheet
<blank> Function has no Parameter or Type :uut Refers to most recent invocation of a unit
under test
Configuration options
:stub Refers to most recent invocation of a
Test tables stubbed function
Blackbox Tests in current sheet will be applied as
black box tests
New test Specifies the beginning of a new set of
Control flow Expects all stub operations written to tests
respect control flow Types and modifiers
End tests Specifies the end of a test table
Disabled Tests in current sheet will not be run A type-signature is defined as
Test details + meaning
modifier* named_type
Applies metadata such as test name to all
Explicit stubs tests in table Possible modifiers are:
Expects that the number of times each
Test details + Value array[len] An array of length len
stubbed function is called is specified
Applies metadata such as test name to
pointer A dereferencable pointer to the type
Remove original stubs only test in current column
Removes original versions of stubbed reference A C++ type reference
Object Specifies a C++ class object
functions from test harness
volatile An object that must be read from memory
Call or stub Unit under test or stub function to apply and cannot be cached in a register
Special syntax operation on
const An object that cannot be modified through
# Comment entire row (should only be Variable Variable to apply operation on assignments
placed in column B) Types must be specified in modification order
Operation Operation to apply to call or stub
: Ignore the operation in this row Example: a constant pointer to an array containing 5 int
Value Value to apply operation with
elements must be specified as
const pointer array[5] int
For an electronic copy see RVS/doc/RapiTest
Spreadsheet Test Format Cheat Sheet (Page 2 of 2)
Basic operations Numerical operations Auxiliary test functions
call Used to call a function, often the check.ne Checks Variable is not equal to Value get.bitsz(obj)
:original version of a stubbed function Returns the size of obj in bits
check.lt Checks Variable is less than Value
called Checks stub is called Value times (unless get.bytesz(obj)
using Control flow) check.le Checks Variable is less than or equal to Returns the size of obj in bytes
Value
catch Checks exception (Value) is raised get.first(obj)
check.gt Checks Variable is greater than Value
Returns the lowest possible value for obj
check Checks value of Variable is Value
check.ge Checks Variable is greater than or equal to given its type
fail Reports test as failed when reached Value
get.invalid(obj)
pass Reports test as passed when reached Returns an invalid value for obj
check.eq(num)
run Invokes a unit under test Checks floating point Variable is within get.last(obj)
num of Value
set Sets value of Variable to Value Returns the highest possible value for obj
check.eq(num%) given its type
stubbed Specifies that a function in the stubs table Checks floating point Variable is within
is stubbed during a test num% percent of Value return References the return value of a unit under
test or stubbed function
check.string Checks value of Variable is equal to a
Arrays “<string>” or another variable in Value
column
Test Locals
{X, Y, Z} (Test Locals) Initializes an array with
elements X, Y, Z Element Specifies sub-elements of structure type
get.length(array) Initializer Specifies values to initialize for local
Returns the length of array Pointers/accesses
init (operation)
array[x] References x’th element in array get.pointer(obj) (Operation) Initializes the initializer
array[x..y] Iterates between the x’th to y’th Returns the pointer/access to obj specified in Value field
elements in array (C/C++ only)
get.address(obj)
Returns the address of obj Raw code
Control flow get.deref(obj) raw: Inserts following code into test as written
called | <blank> Dereferences obj one level raw(type): Specifies type of the following raw code
Specifies that stub is called once
get.object(obj) rts: Inserts following code into test as RTS
Fully dereferences obj script
For an electronic copy see RVS/doc/RapiTest

3029
docs-extracted/src/scov/RVS/doc/RapiTest/Spreadsheet_Test_Format_User_Guide.md Normal file
View file

File diff suppressed because it is too large Load diff

1036
docs-extracted/src/scov/RVS/doc/Reference/Integration_Library_Implementation.md Normal file
View file

File diff suppressed because it is too large Load diff

4670
docs-extracted/src/scov/RVS/doc/Reference/RVS_Annotations.md Normal file
View file

File diff suppressed because it is too large Load diff

1833
docs-extracted/src/scov/RVS/doc/Reference/RVS_Files.md Normal file
View file

File diff suppressed because it is too large Load diff

3000
docs-extracted/src/scov/RVS/doc/Reference/RVS_Filters.md Normal file
View file

File diff suppressed because it is too large Load diff

9891
docs-extracted/src/scov/RVS/doc/Troubleshooting_Guide.md Normal file
View file

File diff suppressed because it is too large Load diff

947
docs-extracted/src/scov/RVS/doc/Using_RVS_with_Jenkins.md Normal file
View file

@ -0,0 +1,947 @@
---
title: "Using Rvs With Jenkins"
source: "./src/scov/RVS/doc/Using_RVS_with_Jenkins.pdf"
category: "src/scov/RVS/doc"
pages: 34
extracted: "2026-07-06T23:15:57.812147"
---
# Using Rvs With Jenkins
> Extracted from `./src/scov/RVS/doc/Using_RVS_with_Jenkins.pdf` (34 pages).
> Figures, diagrams, and tables may not render accurately in plain text.
Using RVS with Jenkins
Version WF20190404
Disclaimer
The information, text, and graphics contained within this document are
provided for information purposes only by Rapita Systems Ltd. Rapita
Systems Ltd. does not warrant the accuracy or completeness of the
information, text, and other items contained in this document.
Copyright and Trademarks
All rights reserved. Information and images contained within this doc-
ument are copyright and the property of Rapita Systems Ltd. All trade-
marks are hereby acknowledged to be the properties of their respective
owners.
Acknowledgments
Rapita Systems' tools are built using AdaCore's GNAT Pro compiler.
Rapita Systems Ltd.
Registered in the UK, number 5011090.
Registered address:
Atlas House
Link Business Park
Osbaldwick Link Road
York
YO10 3JB
UK
Phone: +44 (0) 1904 413 945
http://www.rapitasystems.com/
This document copyright © 2018-2019, Rapita Systems Ltd.
Document build 118520
ID: DOC/18070
Table of Contents
1. About this guide ............................................................... 5
1.1. Structure of this guide ........................................................... 5
1.2. Notation ............................................................................ 5
1.3. RVS documentation map ........................................................ 6
1.4. Support ............................................................................. 7
2. Getting started .................................................................. 9
2.1. Installing RVS on your Jenkins server ......................................... 9
2.2. Creating an RVS project ......................................................... 9
3. Configuring an integration ............................................... 11
3.1. Configuring an integration through a freestyle project ..................... 11
3.2. Configuring an integration through a manual pipeline ..................... 16
3.3. Configuring an integration through a Blue Ocean pipeline ................ 18
4. Viewing results ................................................................ 23
4.1. Jenkins project summary ...................................................... 23
4.2. RVS Project Summary .......................................................... 25
4.3. Build reports ..................................................................... 29
4.4. Execution info .................................................................... 33
Using RVS with Jenkins vWF20190404 3
This page intentionally left blank
1 About this guide
This guide explains how to use RVS with the Jenkins continuous integration server.
It is intended for people who want to configure RVS to work with Jenkins or view
results generated from RVS analysis run through Jenkins.
1.1 Structure of this guide
This document includes the following chapters:
Chapter 1: About this guide
Describes the purpose and layout of the and the notation used throughout the
document.
Chapter 2: Getting started
Describes what you need to do to get started using RVS with the Jenkins contin-
uous integration server.
Chapter 3: Configuring an integration
Describes how to configure RVS builds to run on the Jenkins server through either
freestyle project, Jenkins pipelines or Blue Ocean pipelines.
Chapter 4: Viewing results
Describes how to view RVS results generated by Jenkins in the Jenkins workspace.
1.2 Notation
This document uses the following notation:
• References to other documents and to other chapters or sections in this doc-
ument are written in italics, for example Chapter 1: About this guide. When
reading an electronic copy of this document, you can click on a reference to
navigate to the location of the referenced element.
• Names of RVS applications are formatted in bold italics, for example RVS
Project Manager.
• References to areas or elements in user interfaces are formatted in italics, for
example the Report Navigator.
• Menus, menu choices and button labels are formatted in bold, for example
File » Print or OK. Where buttons have icons, these are shown before their
Label in in-line text, for example Save.
• Names of RVS tools are formatted in bold, for example rvsdriver.
• References to HTML links appear as underlined text, for example
www.rapitasystems.com.
Using RVS with Jenkins vWF20190404 5
RVS documentation map About this guide
• Folder and file names are formatted in a monospaced font.
• Command-line tools and their commands, annotations and examples are for-
matted in a monospaced font. These are either written in-line with text
or as separate text blocks. When written in-line with text, they are formatted
like the following: rvsdriver, default_instrument, rvs_instr.h.
When written as a separate text block, they are formatted like the examples
below:
rvsdriver --project rvs.rvsprj --all
#pragma RVS instrument( "function_name", "FALSE" )
• When referencing Ada code, the term functions refers to both functions and
procedures.
1.3 RVS documentation map
This document is part of the Rapita Verification Suite (RVS) document set, which
contains the following documents:
RVS Installation and Licensing Guide
Describes how to install RVS tools, and licensing options for them.
RVS Integration Guide
Describes how to integrate RVS tools into build and target environments.
RVS User Guide
Describes how to set up and run RVS projects, analyze data and export verification
results.
RapiTest User Guide
Describes how to use RapiTest to manage test projects.
Spreadsheet Test Format User Guide
Describes how to write tests for RapiTest in the Spreadsheet Test Format.
RapiCover User Guide
Describes how to use RapiCover to measure code coverage and address cover-
age holes.
RapiTime User Guide
Describes how to use RapiTime to measure timing metrics including worst-case
execution time, and how to use these metrics to identify the best optimization
candidates.
RapiTask User Guide
Describes how to use RapiTask to measure system level task timing information,
visualize traces and gain insight into runtime behavior.
6 Using RVS with Jenkins vWF20190404
About this guide Support
RTBx 2xxx User Guide
Describes how to use the RTBx data logger.
RVS Integration Library Implementation Guide
Describes how to implement RVS integration libraries. This document is for use by
readers with a thorough understanding of the implementation of RVS.
RVS Files Reference Guide
Describes RVS-specific files including input, intermediate and output files.
RVS Filters Guide
Describes RVS filters, which are used to convert raw trace data into a format that
RVS can analyze, and how to write them.
RVS Command Line Tools Reference Guide
Describes the command-line tools used by RVS, including a list of available com-
mand options.
RVS Annotations Reference Guide
Describes the annotations you can use to control instrumentation and analysis
with RVS.
RVS Troubleshooting Guide
Describes the error and warning messages you may encounter when using RVS
tools, and how to address them.
RVS Migration Guide
Describes how to migrate between using different versions of RVS.
1.4 Support
For support issues, please contact Rapita Systems Ltd. by any of the following
means:
Email
support@rapitasystems.com
Telephone
+44 (0) 1904 413 945
Website
www.rapitasystems.com
To register for support, visit www.rapitasystems.com/register. More than one user
can register per license.
Using RVS with Jenkins vWF20190404 7
This page intentionally left blank
2 Getting started
Before you can get started using RVS with Jenkins, you need to install RVS on your
Jenkins server and create an RVS project suitable for building and analyzing your
code, as described in the following sections.
2.1 Installing RVS on your Jenkins server
Before you can use Jenkins to run continuous builds of your code with RVS, you
need to install RVS on your Jenkins server by following the steps below:
1. First, install the RVS software on the server, or the machine used to run the
Jenkins builds. To learn how to install the RVS software, see the RVS Instal-
lation and Licensing Guide.
Note
If you want to use RVS to produce verification results through Jenkins, you
should install RVS for the same architecture as your Jenkins installation (on
Windows systems, this is usually 32-bit).
2. Next, install the Jenkins plugins that RVS needs to run on your Jenk-
ins server. RVS includes two Jenkins plugins, an execution plugin (which
lets you configure an RVS integration) and a reporter plugin (which lets
you view results from your builds). Both of these are located in the
RVS/integration_resources/plugins/ci_server/jenkins
folder. To learn how to install plugins into Jenkins, see the Jenkins documen-
tation available online at https://jenkins.io/doc/book/managing/plugins/.
2.2 Creating an RVS project
Before you can use Jenkins to run continuous builds of your code with RVS, you
need to create an RVS project that can build and analyze your code. You can use
the following resources to learn how to do so:
• The RVS Integration Guide describes how to integrate RVS with your build sys-
tem and target hardware.
• The RVS User Guide and the RVS tool (RapiTest, RapiCover and RapiTime)
User Guides describe how to create an RVS project file compatible with an
RVS integration.
• The Creating a project tutorials available through the RVS Project Manager
walk you through creating an RVS project file compatible with an RVS integra-
tion.
Using RVS with Jenkins vWF20190404 9
This page intentionally left blank
3 Configuring an integration
Note
Jenkins runs the version of RVS set in the RVS_PATH environment variable.
This environment variable is set by default when you install RVS on a sys-
tem.
Note
Before you can configure RVS to run through Jenkins, you must have an
RVS project set up to build your code. If you do not have a suitable RVS
project, see Section 2.2 to learn how to create one.
This chapter describes how to configure Jenkins to run the RVS execution and
reporter plugins so RVS is able to build and run your code and produce results
on the Jenkins server.
You can configure the RVS execution and reporter plugins to run in one of three
ways:
• Through a freestyle Jenkins project. Section 3.1: Configuring an integration
through a freestyle project describes how to do this.
• Through a Jenkins pipeline. Section 3.2: Configuring an integration through
a manual pipeline describes how to do this. For more information on Jenk-
ins pipelines, see the Jenkins user documentation available online at https://
jenkins.io/doc/book/pipeline/.
• Through a Blue Ocean pipeline. Section 3.3: Configuring an integration through
a Blue Ocean pipeline describes how to do this. For more information on
Blue Ocean pipelines, see the Jenkins user documentation available online at
https://jenkins.io/doc/book/blueocean/.
3.1 Configuring an integration through a freestyle
project
To begin configuring a manual integration of the RVS plugins with Jenkins, click
New Item on the Jenkins sidebar. Next, select Freestyle project, enter a
name for your project, and click OK, see Figure 3.1.
Using RVS with Jenkins vWF20190404 11
Configuring an integration through a freestyle
Configuring an integration
project
Figure 3.1: Adding a freestyle project
In the Build section of your project, open the Add build step drop-down menu and
select Configure RVS execution to add an instance of the RVS execution plugin
to your project.
The RVS execution plugin is displayed at the end of your current build settings,
see Figure 3.2.
12 Using RVS with Jenkins vWF20190404
Configuring an integration through a freestyle
Configuring an integration
project
Figure 3.2: RVS execution plugin
Note
The RVS execution plugin includes help messages, which you can click for
more information and tips on configuring the plugin.
Note
Many settings in the RVS execution plugin require you to enter paths to files.
If the computer you are using to configure the build is the same one that will
be used to run it, you can specify either absolute paths or paths relative to
the Jenkins workspace.
If the computer you are using to configure the build is not the one that will
run it, you must specify paths relative to the Jenkins workspace.
In the Input section, specify the path to your RVS project file, and the integration
within it that you want to run during your Jenkins build, see Figure 3.3. For more
information on RVS projects and integrations, see the RVS User Guide.
Using RVS with Jenkins vWF20190404 13
Configuring an integration through a freestyle
Configuring an integration
project
Figure 3.3: Project and integration settings
You can specify the path to the project as either a path relative to the Jenkins
workspace or, if the computer you are configuring the build from will run the build,
as an absolute path.
The Integration setting contains a drop-down menu that lets you select from the in-
tegrations available in the listed RVS project file. If Jenkins cannot find your project
file (for example because it will be loaded during your Jenkins build), you can
specify the integration name by entering it manually.
In the Basic options section, specify basic rvsdriver options to run during the Jenk-
ins build by using the checkboxes, see Figure 3.4. For more information on the
role of rvsdriver in RVS integrations, see Chapter 8 in the RVS User Guide. For
a detailed description of rvsdriver options, see Chapter 12 in the RVS Command
Line Tools Reference Guide.
Figure 3.4: Basic options
If you are using RapiTest to run functional tests of your code, you must specify a
set of tests to run during your Jenkins builds in the RVS Test Suites section, see
Figure 3.5.
Figure 3.5: RVS Test Suites
14 Using RVS with Jenkins vWF20190404
Configuring an integration through a freestyle
Configuring an integration
project
You can specify tests in any combination of the following ways:
• Run tests from project – you can run all tests specified in the RVS project file.
This option is only selectable if the project file is accessible.
• Run tests from a specific folder – you can specify a folder to tell RVS to run
all tests from within this folder (including those within subfolders).
• Run tests in specified paths – you can specify a list of tests to run. All tests
from the list will be run when Jenkins builds your code. Tests in the list must
be line-separated.
• Run tests defined in a file – you can create a file containing a list of tests to
run and configure RVS to run the tests in this file during your run. Tests in the
file must be line-separated.
To specify tests, use the checkboxes to select which option(s) you would like to
use, and enter settings in the text boxes. In each case, paths you specify can be
either relative to the Jenkins workspace or, if the computer you are configuring the
build from will run the build, as absolute paths.
For more information on RapiTest tests, see the RapiTest User Guide.
Optionally, you can specify advanced options to rvsdriver in the Advanced options
section. To do so, expand the section and manually enter the commands you want
to add to your integration. For more information on the role of rvsdriver in RVS
integrations, see Chapter 8 in the RVS User Guide, and for a detailed description
of rvsdriver options, see Chapter 12 in the RVS Command Line Tools Reference
Guide.
You can view the command line that will be generated when Jenkins calls RVS
while building your code. To do so, expand the Command line section.
Note
In some cases, for example when you have specified a folder containing
RapiTest tests to run, the command line displayed may not exactly match
the one that is run by Jenkins.
Next, click Add post-build action and select Publish RVS results. This adds an in-
stance of the RVS reporter plugin, see Figure 3.6.
Figure 3.6: RVS reporter plugin
The RVS reporter plugin processes XML format export files from RVS projects to
produce a report that you can view and analyze on the Jenkins server, see Chap-
ter 4.
Using RVS with Jenkins vWF20190404 15
Configuring an integration through a manual
Configuring an integration
pipeline
Note
By default, the RVS reporter plugin automatically runs exporters, ensuring
that results are exported from the project. If, for some reason, you want to
use existing (XML format) export files that have already been produced, you
can select to do so by expanding the Advanced options and selecting Man-
ual.
Finally, finish configuring your execution by clicking Save.
If you have configured your execution appropriately, RVS will automatically be run
every time Jenkins builds your code, and RVS results will be available to view in
future Jenkins build reports. To learn how to view results from RVS executions in
Jenkins, see Chapter 4.
3.2 Configuring an integration through a manual
pipeline
Note
This section describes how to configure RVS plugins for Jenkins to run dur-
ing Jenkins pipelines, but does not describe how to use Jenkins pipelines in
detail.
For information on using Jenkins pipelines, see the Jenkins user documen-
tation available online at https://jenkins.io/doc/book/pipeline/.
To begin configuring an integration of the RVS plugins with Jenkins through a
pipeline, click New Item on the Jenkins sidebar. Next, select Pipeline, enter a
name for your pipeline, and click OK, see Figure 3.7.
16 Using RVS with Jenkins vWF20190404
Configuring an integration through a manual
Configuring an integration
pipeline
Figure 3.7: Adding a pipeline project
Navigate to the Pipeline section and click Pipeline Syntax to open the Jenkins
Snippet Generator, see Figure 3.8. You need to add snippets to run both the RVS
execution and reporter plugins, one after the other.
Figure 3.8: Opening the Snippet Generator
To add a script to run the RVS execution plugin, do the following:
1. In the Steps section of the Snippet Generator, open the Sample Step drop-
down menu and select rvsExecution: Configure RVS execution.
Using RVS with Jenkins vWF20190404 17
Configuring an integration through a Blue Ocean
Configuring an integration
pipeline
2. Configure the plugin as described in Section 3.1: Configuring an integration
through a freestyle project.
3. Click Generate Pipeline Script to generate a snippet to add to your pipeline,
see Figure 3.9.
4. Copy the generated snippet to your system's clipboard, return to the browser
window on which you're creating your pipeline, and paste the snippet into
the Script field for your pipeline.
Figure 3.9: Generating a pipeline snippet
Next, add a snippet to run the RVS reporter plugin to your script by following the
process above but selecting the rvsResultReporter: Publish RVS results Sam-
ple Step. To learn how to configure the RVS reporter plugin, see Section 3.1: Con-
figuring an integration through a freestyle project.
3.3 Configuring an integration through a Blue Ocean
pipeline
Note
This section describes how to configure RVS plugins for Jenkins to run us-
ing a Blue Ocean pipeline, but does not describe how to use Blue Ocean
pipelines in detail.
For information on using Blue Ocean pipelines, see the Jenkins user docu-
mentation available online at https://jenkins.io/doc/book/blueocean/.
To begin configuring an integration of the RVS plugins with Jenkins through a Blue
Ocean pipeline, click Open Blue Ocean on the Jenkins sidebar. Next, click New
Pipeline.
On the first screen, add settings for the source code repository you save your code
to, then click Create Pipeline, see Figure 3.10.
18 Using RVS with Jenkins vWF20190404
Configuring an integration through a Blue Ocean
Configuring an integration
pipeline
Figure 3.10: Selecting a source code repository
You will need to add two stages to your Blue Ocean pipeline to run one after the
other: first, one to run the RVS execution plugin, and next, one to run the RVS
reporter plugin.
First, click the plus icon to add a new stage to run the RVS execution plugin. Name
the stage, for example Build and test, and click Add step. Select Config-
ure RVS execution from the list of steps, see Figure 3.11.
Figure 3.11: Adding a stage to run the RVS execution plugin
Using RVS with Jenkins vWF20190404 19
Configuring an integration through a Blue Ocean
Configuring an integration
pipeline
Note
Many settings in the RVS execution plugin require you to enter paths to files.
If the computer you are using to configure the build is the same one that will
be used to run it, you can specify either absolute paths or paths relative to
the Jenkins workspace.
If the computer you are using to configure the build is not the one that will
run it, you must specify paths relative to the Jenkins workspace.
Configure settings for the RVS execution plugin, see Figure 3.12.
Figure 3.12: Blue Ocean RVS execution plugin settings
Note
The RVS execution plugin is not fully compatible with Blue Ocean visual
pipelines.
While most of the functionality available in manual configurations of the plu-
gin are also available in Blue Ocean visual pipelines, some configuration
options do not work as expected. As such, we recommend that you ignore
any options not specified below.
20 Using RVS with Jenkins vWF20190404
Configuring an integration through a Blue Ocean
Configuring an integration
pipeline
In the RvsProjectFilePath and Integration fields, specify the path to your RVS project
file and the RVS integration within it that you want to run it that you want to run
during your Jenkins build. You can specify the path to the project as either a path
relative to the Jenkins workspace or, if the computer you are configuring the build
from will run the build, as an absolute path.
For more information on RVS projects and integrations, see the RVS User Guide.
The main RVS command-line tool is rvsdriver. In the AdvancedOptions field, and
the subsequent checkboxes, specify which rvsdriver commands you want to run
during your Jenkins build.
For more information on the role of rvsdriver in RVS integrations, see Chapter 8
in the RVS User Guide. For a detailed description of rvsdriver options, see Chap-
ter 12 in the RVS Command Line Tools Reference Guide
If you are using RapiTest to run functional tests of your code, specify a set of tests
to run during your Jenkins builds using the TestFile and/or TestFolder fields:
• TestFile – specify the path to a file containing a list of tests, with each test
separated by a newline.
• TestFolder – specify the path to a folder containing tests.
For more information on RapiTest tests, see the RapiTest User Guide.
When you have finished configuring a stage to run the RVS execution plugin, click
the plus icon in the main window to add a new stage to run the RVS reporter
plugin. Name the stage, for example Report, and click Add step. Select Pub-
lish RVS results from the list of steps, see Figure 3.13.
Figure 3.13: Adding a stage to run the RVS reporter plugin
The RVS reporter plugin processes XML format export files from RVS projects to
produce a report that you can view and analyze on the Jenkins server, see Chap-
ter 4.
The RVS reporter plugin can process export files sourced in a variety of ways.
By default, it searches the project workspace for export files. For this to work,
Using RVS with Jenkins vWF20190404 21
Configuring an integration through a Blue Ocean
Configuring an integration
pipeline
your instance of the RVS execution plugin must produce an XML export file in this
workspace when it runs your project.
If your instance of the RVS execution plugin produces an XML export file, but this
is not saved in the project workspace, you can enter the path to an ExportFolder
containing the file, see Figure 3.14.
Figure 3.14: RVS reporter plugin – settings
Alternatively, you can configure the plugin to produce exports itself by checking
the RunExporters checkbox.
Finally, click Save and follow the on-screen prompts to save your Blue Ocean
pipeline.
22 Using RVS with Jenkins vWF20190404
4 Viewing results
This chapter describes how to view RVS results in the RVS reporter plugin. It con-
tains the following sections:
• Section 4.1: Jenkins project summary describes the trend graphs displayed in
the Jenkins project summary.
• Section 4.2: RVS Project Summary describes the results shown in the over-
all RVS summary, which include information on trends across builds in your
project.
• Section 4.3: Build reports describes the results shown in individual RVS build
reports, which include detailed information.
4.1 Jenkins project summary
If you have configured an RVS execution plugin appropriately, one or more graphs
showing trends in your results across your Jenkins builds is displayed on your
Jenkins project's main page depending on the type of results you are collecting.
If you are using RapiTest to collect unit test results, these are shown on the
Trend (Test Results) chart, see Figure 4.1.
Figure 4.1: Jenkins project summary trend graphs
If you are using RapiCover to collect coverage results, these are shown on the
Trend (Coverage Results) chart, see Figure 4.2.
Using RVS with Jenkins vWF20190404 23
Jenkins project summary Viewing results
Figure 4.2: Jenkins project summary trend graphs
If you are using RapiTime to collect execution time results, these are shown on the
Trend (Timing Results) chart, see Figure 4.3.
Figure 4.3: Jenkins project summary trend graphs
24 Using RVS with Jenkins vWF20190404
Viewing results RVS Project Summary
Tip
Trend graphs are interactive, and let you do the following:
• View more detailed information for a build by hovering over it in the
graph.
• Rescale the graph to show more or fewer builds (all graphs), or zoom
into a specific region on the y-axis (coverage or timing trend graphs).
• Toggle whether or not a metric is displayed on the graph by clicking on
the legend entry for that metric in the graph.
• Open the build report for a specific build by clicking on the bar
(RapiTest trend graphs) or hollow circles (RapiCover and RapiTime
trend graphs) associated with that build.
• Change whether results are reported by build number or date and time
by selecting either Show builds or Show dates, respectively.
4.2 RVS Project Summary
Your Jenkins project includes a summary of all of the RVS data collected from
your Jenkins builds. To open this, click RVS Project Summary from the Jenkins
sidebar.
Figure 4.4: Opening the RVS Project Summary
Using RVS with Jenkins vWF20190404 25
RVS Project Summary Viewing results
The RVS Project Summary opens on an Overview page, which includes larger ver-
sions of the trend graphs displayed on the Jenkins project summary page, see
Section 4.1: Jenkins project summary.
If your Jenkins project uses RapiTest and/or RapiCover, the RVS Project Summa-
ry also includes detailed pages containing data collected by these tools, as de-
scribed in the following sections.
4.2.1 RVS Project Summary: Detailed Test Data
If your Jenkins project uses RapiTest to collect results from functional tests of your
code, these are displayed in the Detailed Test Data tab on the RVS Project Sum-
mary.
Figure 4.5: RVS Project Summary: Detailed Test Data
The page includes a trend graph of your test results, as shown on the Jenkins
project summary and RVS Project Summary pages.
The Test suites used in this build table shows all tests included in the latest build.
If your most recent build did not run some of the tests that were run in the most
recent (up to 10) builds, an additional table lists these tests.
You can filter the trend graph to only show results for a specific test by selecting
that test in either of the tables, see Figure 4.6.
26 Using RVS with Jenkins vWF20190404
Viewing results RVS Project Summary
Figure 4.6: Filtering the tests trend graph
To return to viewing all tests in the trend graph, click Overall.
Tip
If your project contains many tests, these may not all be displayed at once
in the tables.
You can configure the tables to display more entries by using the Show #
entries drop-down menu, and navigate between multiple pages showing
entries by using the Next and Previous buttons.
You can also enter a filter string in the Search ... button to filter results
shown in either of the tables.
4.2.2 RVS Project Summary: Detailed Coverage Data
If your Jenkins project uses RapiCover to collect structural coverage results from
your code, these are displayed in the Detailed Coverage Data tab on the RVS
Project Summary.
Using RVS with Jenkins vWF20190404 27
RVS Project Summary Viewing results
Figure 4.7: RVS Project Summary: Detailed Coverage Data
The page includes a trend graph of your coverage results, as shown on the Jenkins
project summary and RVS Project Summary pages.
The table shows all of the folders included in your project. You can filter the trend
graph to only show results for a specific folder by selecting that folder in the table,
see Figure 4.8.
Figure 4.8: Filtering the coverage trend graph
To return to viewing coverage from all folders in the trend graph, click Overall.
28 Using RVS with Jenkins vWF20190404
Viewing results Build reports
Tip
If your project contains many folders, these may not all be displayed at
once.
You can configure the table to display more entries by using the Show # en-
tries drop-down menu, and navigate between multiple pages showing en-
tries by using the Next and Previous buttons.
You can also enter a filter string in the Search ... button to filter results
shown in the table.
4.3 Build reports
You can view a detailed report for each of your builds. This includes a textual
overview of data collected during the build, and a number of pages containing
more detailed data, depending on which RVS tools were used during the build.
To open a build report, click on the build number for the build you want to view
data for in your Jenkins Build History, then RVS Build Report. Alternatively, your
build report will open if you click on the bar or hollow circles associated with that
build on a trend graph (see Section 4.1).
Figure 4.9: Opening a build report
The Overview page includes a textual summary of results from the RVS tools used
to analyze your code as well as information collected from static analysis, such as
the number of lines of source code analyzed during the build, see Figure 4.10.
Using RVS with Jenkins vWF20190404 29
Build reports Viewing results
Figure 4.10: Build report overview
A number of additional pages are shown depending on which RVS tools were
used to collect data during the build. The data shown on these pages is described
in the following sections.
4.3.1 Build report: Unit Tests page
If RapiTest was used during a build, the build report includes a Unit Tests page,
see Figure 4.11.
30 Using RVS with Jenkins vWF20190404
Viewing results Build reports
Figure 4.11: Build report: Unit Tests page
The Unit Tests Results graph shows a summary of the test results achieved during
a build. You can toggle whether or not a metric (such as Failed) is shown by
clicking on the legend entry for that metric.
The table underneath the chart shows a detailed breakdown of results for each
test in a test suite.
Tip
If your project contains many test suites, these may not all be displayed at
once.
You can configure the table to display more entries by using the Show # en-
tries drop-down menu, and navigate between multiple pages showing en-
tries by using the Next and Previous buttons.
You can also enter a filter string in the Search ... button to filter results
shown in the table.
4.3.2 Build report: Coverage page
If RapiCover was used during a build, the build report includes a Coverage page,
see Figure 4.12.
Using RVS with Jenkins vWF20190404 31
Build reports Viewing results
Figure 4.12: Build report: Coverage page
The Coverage Summary graph shows a summary of the coverage achieved across
all source code analyzed during a build. You can toggle whether or not a metric
(such as Uncovered) is shown by clicking on the legend entry for that metric.
The table underneath the chart shows a detailed breakdown of coverage per cov-
erage type and folder analyzed.
Tip
If your project contains many folders, these may not all be displayed at
once.
You can configure the table to display more entries by using the Show # en-
tries drop-down menu, and navigate between multiple pages showing en-
tries by using the Next and Previous buttons.
You can also enter a filter string in the Search ... button to filter results
shown in the table.
32 Using RVS with Jenkins vWF20190404
Viewing results Execution info
4.3.3 Build report: Timing data page
If RapiTime was used during a build, the build report includes a Timing data page,
see Figure 4.13.
Figure 4.13: Build report: Timing data page
The graph shows a summary of the timing data collected during the build. You
can toggle whether or not a metric (such as Min_ET) is shown by clicking on the
legend entry for that metric.
4.4 Execution info
You can view additional information for each execution of RVS during your build.
To view this information, click on the build number for the build you want to view
data for in your Jenkins Build History, then click RVS Execution Info.
The execution info screen shows whether the execution passed or failed, provides
a link to let you download the RVS report associated with the execution, and dis-
plays the RVS log from the execution, see Figure 4.14.
Figure 4.14: RVS execution info
Using RVS with Jenkins vWF20190404 33
This page intentionally left blank

228
docs-extracted/src/scov/RVS/integration_resources/reference/integration_annexes/Compilers/rvs-ig-compilers-cl500.md Normal file
View file

@ -0,0 +1,228 @@
---
title: "Rvs Ig Compilers Cl500"
source: "./src/scov/RVS/integration_resources/reference/integration_annexes/Compilers/rvs-ig-compilers-cl500.pdf"
category: "src/scov/RVS/integration_resources/reference/integration_annexes/Compilers"
pages: 12
extracted: "2026-07-06T23:15:03.202506"
---
# Rvs Ig Compilers Cl500
> Extracted from `./src/scov/RVS/integration_resources/reference/integration_annexes/Compilers/rvs-ig-compilers-cl500.pdf` (12 pages).
> Figures, diagrams, and tables may not render accurately in plain text.
cl500 Integration Annex
Version WF20190404
Disclaimer
The information, text, and graphics contained within this document are
provided for information purposes only by Rapita Systems Ltd. Rapita
Systems Ltd. does not warrant the accuracy or completeness of the
information, text, and other items contained in this document.
Copyright and Trademarks
All rights reserved. Information and images contained within this doc-
ument are copyright and the property of Rapita Systems Ltd. All trade-
marks are hereby acknowledged to be the properties of their respective
owners.
Acknowledgments
Rapita Systems' tools are built using AdaCore's GNAT Pro compiler.
Rapita Systems Ltd.
Registered in the UK, number 5011090.
Registered address:
Atlas House
Link Business Park
Osbaldwick Link Road
York
YO10 3JB
UK
Phone: +44 (0) 1904 413 945
http://www.rapitasystems.com/
This document copyright © 2019, Rapita Systems Ltd.
Document build 118520
ID: DOC/16075
1 cl500 compiler wrapper
This Integration Annex describes how to install and configure the RVS cl500 com-
piler wrapper, which can be used with Code Composer Studio 2.2 to seamlessly
preprocess and instrument source files as they are compiled. This allows the RVS
tools to be integrated without the need to alter the build system.
1.1 Integrating with Code Composer Studio 2.2
This section provides a guide on how to integrate RVS with Code Composer Stu-
dios 2.2 on Microsoft Windows.
1.1.1 Installing the compiler wrapper
Run the Configure RVS Compiler Wrappers executable that came with the RVS
install.
Figure 1.1: Running Configure RVS Compiler Wrappers
Select to install the cl500 compiler wrapper and click next.
RVS Integration Guide WF20190404 — cl500 Integration Annex 3
Integrating with Code Composer Studio 2.2 cl500 compiler wrapper
Figure 1.2: Selecting cl500 compiler wrapper
Enterthe folder in which cl500 is located, by default this is
C:\ti\c5400\cgtools\bin and click next.
Figure 1.3: Choosing directory of cl500
Select to wrap the compiler and click next and then finish.
Figure 1.4: Wrapping the compiler
1.1.2 Setting up the build configuration
The next steps detail how to create a build configuration that includes compiler
wrapper arguments.
Start Code Composer Studio 2.2 and open the project you want to instrument.
4 RVS Integration Guide WF20190404 — cl500 Integration Annex
cl500 compiler wrapper Integrating with Code Composer Studio 2.2
In the project view, right click the project and select Configurations.
Figure 1.5: Opening the build configuration window
In the build configuration window select Add, to add a new build configuration.
Figure 1.6: Adding a new build configuration
In the Add Project Configuration window, name the new configuration that will be
used for the instrumented build. Ensure that the Copy Settings From field is set
to the name of the original build configuration, then click OK to create the new
configuration.
RVS Integration Guide WF20190404 — cl500 Integration Annex 5
Integrating with Code Composer Studio 2.2 cl500 compiler wrapper
Figure 1.7: Naming the new build configuration
and copy the settings from the original
In the Project Configuration window, set the new instrumented build configuration
to the active configuration by selecting it and clicking the Set Active button. Then
click Done to accept the change.
Figure 1.8: Setting the active build configuration
Additional arguments need to be added to the compile and link stages of the
build to configure the cl500 compiler wrapper. This can either be done through
environment variables or command line arguments.
The Code Composer Studio 2.2 compiler and linker argument fields do not allow
unrecognized arguments to be entered into them. To work around this limitation
a command file is used to pass in these additional compiler wrapper arguments.
Command files are passed in using the -@<filepath> option in the cl500 compiler
and linker argument fields.
See Section 4.2 in the RVS Integration Guide for more information on configuring
compiler wrapper options.
You must create a command file containing the compiler wrapper arguments you
wish to set (do make sure that any backslashes are backslash escaped).
In the following example a command file will be create at the following path
C:\example\rvs\config\build.config, containing the following text.
6 RVS Integration Guide WF20190404 — cl500 Integration Annex
cl500 compiler wrapper Integrating with Code Composer Studio 2.2
Example 1.1: Setting compiler wrapper arguments via a command file
-RVS=C:\\examples\\rvs -RVSROOT=C:\\RVS3.5
In the project view, right click the project and select Build Options.
Figure 1.9: Opening project build options
In the Build Options window select the Compiler tab. In the options box add
-@<filepath> where <filepath> is the path to the command file you wish to
add.
RVS Integration Guide WF20190404 — cl500 Integration Annex 7
Integrating with Code Composer Studio 2.2 cl500 compiler wrapper
Figure 1.10: Adding wrapper options to the compile stage
In the Build Options window, select the Linker tab and add the same command
file used for the compile stage. Click OK to accept the changes.
8 RVS Integration Guide WF20190404 — cl500 Integration Annex
cl500 compiler wrapper Integrating with Code Composer Studio 2.2
Figure 1.11: Adding wrapper options to the link stage
1.1.3 Running the integration
This section describes how to run the instrumented build to obtain an instrumented
executable and structural report.
Ensure that the instrumented build is selected in the build configuration menu. In
the project view, right click the project and select Configurations.
RVS Integration Guide WF20190404 — cl500 Integration Annex 9
Integrating with Code Composer Studio 2.2 cl500 compiler wrapper
Figure 1.12: Opening the build configuration window
In the Project Configuration window, set the new instrumented build configuration
to the active configuration by selecting it and clicking the Set Active button. Then
click Done to accept the change.
Figure 1.13: Setting the active build configuration
In the project view, right click the project and select Clean.
10 RVS Integration Guide WF20190404 — cl500 Integration Annex
cl500 compiler wrapper Integrating with Code Composer Studio 2.2
Figure 1.14: Cleaning the instrumented project
In the project view, right click the project and select Build.
Figure 1.15: Building the instrumented project
The build should produce an executable containing instrumentation and a sta-
tic report file in the directory <integration_folder>/results, where
<integration_folder> is the location specified by the -RVS option in the command
file used to set wrapper arguments. See Example 1.1 for an example command
file.
RVS Integration Guide WF20190404 — cl500 Integration Annex 11
This page intentionally left blank

164
docs-extracted/src/scov/RVS/integration_resources/reference/integration_annexes/Compilers/rvs-ig-compilers-dcc.md Normal file
View file

@ -0,0 +1,164 @@
---
title: "Rvs Ig Compilers Dcc"
source: "./src/scov/RVS/integration_resources/reference/integration_annexes/Compilers/rvs-ig-compilers-dcc.pdf"
category: "src/scov/RVS/integration_resources/reference/integration_annexes/Compilers"
pages: 6
extracted: "2026-07-06T23:15:03.220854"
---
# Rvs Ig Compilers Dcc
> Extracted from `./src/scov/RVS/integration_resources/reference/integration_annexes/Compilers/rvs-ig-compilers-dcc.pdf` (6 pages).
> Figures, diagrams, and tables may not render accurately in plain text.
Wind River
Diab Compiler
Integration Annex
Version WF20190404
Disclaimer
The information, text, and graphics contained within this document are
provided for information purposes only by Rapita Systems Ltd. Rapita
Systems Ltd. does not warrant the accuracy or completeness of the
information, text, and other items contained in this document.
Copyright and Trademarks
All rights reserved. Information and images contained within this doc-
ument are copyright and the property of Rapita Systems Ltd. All trade-
marks are hereby acknowledged to be the properties of their respective
owners.
Acknowledgments
Rapita Systems' tools are built using AdaCore's GNAT Pro compiler.
Rapita Systems Ltd.
Registered in the UK, number 5011090.
Registered address:
Atlas House
Link Business Park
Osbaldwick Link Road
York
YO10 3JB
UK
Phone: +44 (0) 1904 413 945
http://www.rapitasystems.com/
This document copyright © 2019, Rapita Systems Ltd.
Document build 118520
ID: DOC/12032
1 Wind River Diab Compiler
This Integration Annex highlights some key aspects that must be considered when
RVS is integrated into a build system that makes use of the Wind River Diab Com-
piler.
This first chapter outlines the options required to allow GCC to produce the nec-
essary files for an RVS integration. Chapter 2 provides details of the GCC compiler
wrapper provided with RVS.
For information on using RVS with other development tool-chains, please
see the appropriate Integration Annex for that tool-chain. If further assis-
tance is required, please contact the Rapita Systems Ltd. support team at
support@rapitasystems.com.
1.1 Preprocessing C/C++
These are the options relevant to preprocessing with the Diab Compiler.
Preserve comments
-C
Write preprocessed output to standard output
-E
Write preprocessed output to a file
-E with -@O=<file.pre>
The -@O= is an alternative way to redirect standard output to a file without relying
on the shell.
Important
Comments must be preserved in the preprocessed output to preserve com-
ment-style RVS annotations.
RVS Integration Guide WF20190404 — Wind River Diab Compiler Integration Annex 3
Instrumenter Options Wind River Diab Compiler
Warning
Beware of using these options.
Save temporary files.
-save-temps
This option will keep the assembly output but, unlike the GCC option of the
same name, it will not store the preprocessed output. (version 5.8.0.0)
Preprocess without line markers
-P
This option will write out a preprocessed file but it will not contain line mark-
ers.
1.1.1 Examples
Example 1.1: Using the Diab Compiler to preprocess to standard output and
preserve comments
dcc -C -E path/source/x.c > path/source/x.pre
Example 1.2: Using the Diab Compiler to preprocess to a file and preserve
comments
dcc -C -E path/source/x.c -@O=path/source/x.pre
1.2 Instrumenter Options
Use the --cext DCC option with cins when instrumenting C preprocessed
source code.
Use the --cext DCC option with cppins for instrumenting C++ preprocessed
source code.
1.3 Inlining an RVS_I function
If RVS_I is not written as a macro, it is recommended that it is defined as an inline
function within rvs_ipoint.h.
1.4 Writing inline assembly
The Diab Compiler supports the use of inline assembly code. This section provides
a brief overview of how inline assembly is used with the Diab Compiler and some
useful examples. A full explanation is outside the scope of this guide. For more
information, see the manual for your version of the Diab Compiler.
4 RVS Integration Guide WF20190404 — Wind River Diab Compiler Integration Annex
2 Diab Compiler wrapper
This chapter describes how to install and configure the RVS Diab Compiler wrap-
per, which can be used with a Diab Compiler-based build system to seamlessly
preprocess and instrument source files as they are compiled. This allows the RVS
tools to be integrated without the need to alter the build system.
2.1 Compiler wrapper executables
The following wrapper executables can be found in your installation in
<RVS home>/integration_resources/compiler_wrappers/diab.
• dcc_wrap wraps the dcc compiler.
• dld_wrap wraps the dld linker.
2.2 Using the compiler wrapper in an integration
See the RVS Integration Guide for more information on how to create a compiler
wrapper based integration.
Detailed information about the compiler wrapper options and configuration files
can be found in Section 4.2 in the RVS Integration Guide.
RVS Integration Guide WF20190404 — Wind River Diab Compiler Integration Annex 5
This page intentionally left blank

331
docs-extracted/src/scov/RVS/integration_resources/reference/integration_annexes/Compilers/rvs-ig-compilers-gcc.md Normal file
View file

@ -0,0 +1,331 @@
---
title: "Rvs Ig Compilers Gcc"
source: "./src/scov/RVS/integration_resources/reference/integration_annexes/Compilers/rvs-ig-compilers-gcc.pdf"
category: "src/scov/RVS/integration_resources/reference/integration_annexes/Compilers"
pages: 10
extracted: "2026-07-06T23:15:03.243153"
---
# Rvs Ig Compilers Gcc
> Extracted from `./src/scov/RVS/integration_resources/reference/integration_annexes/Compilers/rvs-ig-compilers-gcc.pdf` (10 pages).
> Figures, diagrams, and tables may not render accurately in plain text.
GCC Integration Annex
Version WF20190404
Disclaimer
The information, text, and graphics contained within this document are
provided for information purposes only by Rapita Systems Ltd. Rapita
Systems Ltd. does not warrant the accuracy or completeness of the
information, text, and other items contained in this document.
Copyright and Trademarks
All rights reserved. Information and images contained within this doc-
ument are copyright and the property of Rapita Systems Ltd. All trade-
marks are hereby acknowledged to be the properties of their respective
owners.
Acknowledgments
Rapita Systems' tools are built using AdaCore's GNAT Pro compiler.
Rapita Systems Ltd.
Registered in the UK, number 5011090.
Registered address:
Atlas House
Link Business Park
Osbaldwick Link Road
York
YO10 3JB
UK
Phone: +44 (0) 1904 413 945
http://www.rapitasystems.com/
This document copyright © 2019, Rapita Systems Ltd.
Document build 118520
ID: DOC/12015
1 GCC options for RVS
This Integration Annex highlights some key aspects that must be considered when
RVS is integrated into a build system that makes use of the GCC toolchain.
This first chapter outlines the options required to allow GCC to produce the nec-
essary files for an RVS integration. Chapter 2 provides details of the GCC compiler
wrapper provided with RVS.
For information on using RVS with other development tool-chains, please
see the appropriate Integration Annex for that tool-chain. If further assis-
tance is required, please contact the Rapita Systems Ltd. support team at
support@rapitasystems.com.
1.1 Preprocessing C/C++
These are the options relevant to preprocessing with GCC compilers.
Preserve comments (required if using comment style annotations in source
code):
-C
Write preprocessed output to standard output:
-E
Example 1.1: Preprocess to standard output and preserve comments:
gcc -DRVS -C -E path/source/x.c > path/source/x.pre
Write preprocessed output to a file:
-E with -o <file>.pre
Example 1.2: Preprocess to a file and preserve comments:
gcc -DRVS -C -E path/source/x.c -o path/source/x.pre
Save preprocessed output in current directory while compiling:
-save-temps
This will produce a preprocessed source file called <file>.i if the input is a C
file and <file>.ii if the input is a C++ file.
<file>.s containing assembly code is also produced.
RVS Integration Guide WF20190404 — GCC Integration Annex 3
Instrumenter Options GCC options for RVS
Both files are stored in the directory the compiler is run from.
Example 1.3: Save preprocessed output in current directory while compiling
gcc -c -DRVS -C -save-temps path/source/x.c -o path/build/x.o
Save preprocessed output in object directory while compiling:
-save-temps=obj
Important
This option is not available before GCC version 4.5. In GCC version 4.5.x a
preprocessed file will not be produced if the input file is detected as C++.
This is remedied in GCC 4.6.x.
This will produce the same files as described above but will store them in the same
folder as the output object file.
Depending on the build system, this can be useful for avoiding name clashes and
supporting multiple build targets.
Example 1.4: Save preprocessed output in object directory while compiling:
gcc -c -DRVS -C -save-temps=obj path/source/x.c -o path/build/x.o
Remove #line directives from preprocessed output:
-P
Warning
Avoid using this option if the output is intended as input to an RVS instru-
menter as the instrumenter will not be able to locate the original source
code if the directives are not present.
1.2 Instrumenter Options
Use the --cext GCC option with cins when instrumenting C preprocessed
source code.
Use the --cext GNU option with cppins for instrumenting C++ preprocessed
source code.
1.3 Inlining an RVS_I function
If RVS_I is not written as a macro, it is recommended that it is defined as an inline
function within rvs_ipoint.h.
4 RVS Integration Guide WF20190404 — GCC Integration Annex
GCC options for RVS Writing inline assembly
With GCC, a function may be declared inline by using the inline keyword in its
declaration (Example 1.5).
Example 1.5: Declaring RVS_I as an inline function
...
static inline void RVS_I(unsigned int I)
{
/* ipoint function code */
}
...
If optimization is disabled, GCC will not inline any functions unless the
always_inline attribute is specified (Example 1.6).
Example 1.6: Using always_inline in a function declaration
...
inline void RVS_I(unsigned int I) __attribute__((always_inline));
...
For more information about inline functions in GCC, see the GCC manual.
1.4 Writing inline assembly
GCC supports the use of inline assembly code. This section provides a brief
overview of how inline assembly is used with GCC and some useful examples. A
full explanation is outside the scope of this guide. For more information, see the
manual for your version of GCC.
The basic format for inline assembly uses the asm statement:
asm ("assembly code");
Where assembly code requires access to C variables for input or output, or where
the assembly code modifies the contents of certain registers, it is necessary to
use the extended assembly syntax:
asm ("assembly code"
: output operands /* optional */
: input operands /* optional */
: list of clobbered registers /* optional */
);
Example 1.7 shows a function which configures performance counter 0 on a Pow-
erPC to count clock cycles. The code writes the value 64 to special purpose reg-
ister 952, via register 0. As register 0 is overwritten by this code, it is included in
the list of clobbered registers.
The volatile keyword is often used with the asm statement to prevent the com-
piler from reordering inline assembly and the code produced by the compiler.
RVS Integration Guide WF20190404 — GCC Integration Annex 5
Writing inline assembly GCC options for RVS
Example 1.7: Configuring UMMCR0 with GCC
void init_ummcr0()
{
asm volatile( "li 0,64\n\t"
"mtspr 952,0"
:
:
: "r0" );
}
Example 1.8 shows how to read the performance counter setup in the above ex-
ample for use as a timestamp. The instruction reads from special purpose register
937 into the variable t. In this example, "=r" is a storage constraint imposed on
variable t. In this case t must be stored in a register.
Example 1.8: Reading UPMC1 with GCC
{
register unsigned int t;
asm volatile( "mfspr %0, 937" : "=r"(t) )
}
GCC supports a large number of operand constraints, some of which are target
specific. A selection of the more common constraints are shown in Table 1.1.
Table 1.1 Selected GCC inline assembly operand constraints
Constraint Description
m A memory operand with any address that the machine supports.
o A memory operand where the address is offsettable, i.e. a small integer
can be added to it and the result is another address.
r The operand must be a general purpose register.
i An immediate integer operand is allowed, including symbolic constants
whose value may not be known before assembly time.
n An immediate integer operand with known numeric value.
g Any general purpose register, memory or immediate integer operand is
allowed.
p Any operand that is a valid memory address is allowed.
A x86 only. Force operand to use registers eax and edx.
Further to these constraints, additional modifiers can be used. = indicates that this
operand is write-only whereas + indicates that the operand is both read and write.
An & character indicates that this value will be clobbered before all input values
have been read. If this is not used on an output operand then the compiler may
use re-use its location after it has been written to within the sequence of assembly
statements.
6 RVS Integration Guide WF20190404 — GCC Integration Annex
GCC options for RVS Writing inline assembly
A further example with an x86 specific constraint is shown in Example 1.9. This
example uses the x86 rdtsc instruction which stores a 64 bit timestamp in reg-
isters eax and edx. The A constraint forces the operand to use these registers.
It also automatically tells the compiler that these registers will be clobbered.
Example 1.9: Using rdtsc with GCC
#define GET_TIMER(t) \
asm volatile( "rdtsc" /* opcode 0x0f31 */ \
: "=A"(t) /* output using eax+edx */ )
RVS Integration Guide WF20190404 — GCC Integration Annex 7
This page intentionally left blank
2 GCC compiler wrapper
This chapter describes how to install and configure the RVS GCC wrapper, which
can be used with a GCC-based build system to seamlessly preprocess and in-
strument source files as they are compiled. This allows the RVS tools to be inte-
grated without the need to alter the build system.
2.1 Compiler wrapper executables
The following wrapper executables can be found in your installation in
<RVS home>/integration_resources/compiler_wrappers/gcc.
• gcc wraps the gcc compiler. It will also wrap the linking stage if your build
system uses the gcc executable for this.
• ld wraps the linking stage. Use this if your build system explicitly calls ld at
the linking stage, rather than using gcc to link.
2.2 Compiler and linker wrapper – modes of operation
The GCC wrapper gcc executable will choose to execute the compiler wrapper,
the linker wrapper or both based on the original command line parameters (as-
suming the wrapper is enabled).
If the command line contains the -c option, then only the compiler wrapper is run.
If the command line does not contain the -c option but does contain one or more
source files (.c extension), then both the compiler wrapper and linker wrapper
actions will take place.
If the command line does not contain the -c and no source files are detected on
the command line then only the linker wrapper actions will be executed.
Certain command line options such as --help cause all wrapper actions to be
disabled.
If the wrapper is executed via the ld executable rather than the gcc executable
then it will always run in linker wrapper mode only. If you do explicitly call ld to link
your application (rather than indirectly through gcc), then any specified options
will also be applied to the ld wrapper as appropriate.
2.3 Using the compiler wrapper in an integration
See the RVS Integration Guide for more information on how to create a compiler
wrapper based integration.
RVS Integration Guide WF20190404 — GCC Integration Annex 9
Using the compiler wrapper in an integration GCC compiler wrapper
Detailed information about the compiler wrapper options can be found in Sec-
tion 4.2 in the RVS Integration Guide.
10 RVS Integration Guide WF20190404 — GCC Integration Annex

259
docs-extracted/src/scov/RVS/integration_resources/reference/integration_annexes/Compilers/rvs-ig-compilers-ghs_multi.md Normal file
View file

@ -0,0 +1,259 @@
---
title: "Rvs Ig Compilers Ghs Multi"
source: "./src/scov/RVS/integration_resources/reference/integration_annexes/Compilers/rvs-ig-compilers-ghs_multi.pdf"
category: "src/scov/RVS/integration_resources/reference/integration_annexes/Compilers"
pages: 6
extracted: "2026-07-06T23:15:03.263402"
---
# Rvs Ig Compilers Ghs Multi
> Extracted from `./src/scov/RVS/integration_resources/reference/integration_annexes/Compilers/rvs-ig-compilers-ghs_multi.pdf` (6 pages).
> Figures, diagrams, and tables may not render accurately in plain text.
Green Hills MULTI
Integration Annex
Version WF20190404
Disclaimer
The information, text, and graphics contained within this document are
provided for information purposes only by Rapita Systems Ltd. Rapita
Systems Ltd. does not warrant the accuracy or completeness of the
information, text, and other items contained in this document.
Copyright and Trademarks
All rights reserved. Information and images contained within this doc-
ument are copyright and the property of Rapita Systems Ltd. All trade-
marks are hereby acknowledged to be the properties of their respective
owners.
Acknowledgments
Rapita Systems' tools are built using AdaCore's GNAT Pro compiler.
Rapita Systems Ltd.
Registered in the UK, number 5011090.
Registered address:
Atlas House
Link Business Park
Osbaldwick Link Road
York
YO10 3JB
UK
Phone: +44 (0) 1904 413 945
http://www.rapitasystems.com/
This document copyright © 2019, Rapita Systems Ltd.
Document build 118520
ID: DOC/13021
1 Green Hills MULTI
1.1 Green Hills MULTI
1.1.1 Preprocessing C/C++
These are the options relevant to preprocessing with Green Hills MULTI.
Preserve comments
-C
Write preprocessed output to standard output
-E
Warning
Take care when using the following options:
Preprocess without line markers
-P
This option will write out a preprocessed file but it will not contain line mark-
ers. Preprocessed output from a C or C++ file is saved with a .i extension.
Avoid using this option if the output is intended as input to an RVS instru-
menter as the instrumenter will not be able to locate the original source
code if the directives are not present.
Profiling
-p -pg -a -timer_profile
These options will cause the timing and coverage information native to
Green Hills MULTI to be generated. Avoid using this option if the build is in-
tended as input to RVS as these are not compatible with wrapper functions.
Examples
Example 1.1: Using Green Hills MULTI to preprocess to standard output and
preserve comments
ccppc -C -E path/source/x.c > path/source/x.pre
RVS Integration Guide WF20190404 — Green Hills MULTI Integration Annex 3
Green Hills MULTI Green Hills MULTI
1.1.2 Instrumenter options
Use the --cext GREENHILLS option with cins for instrumenting C pre-
processed source code.
Use the --cext GREENHILLS option with cppins for instrumenting C++ pre-
processed source code.
1.1.3 Inlining an RVS_I function
If RVS_I is not written as a macro, it is recommended that it is defined as an inline
function within rvs_ipoint.h.
To manually indicate that the compiler should consider a function for inlining, place
an inline keyword immediately before the declaration of the function. There are
four different methods the tool-chain uses to link these functions, depending on
how the function was declared. A list of inline keywords/methods is provided in
the table below.
It is recommended that the static inline method is used.
Table 1.1 Inline keywords
Keyword GNU Dialect C89/C99
inline exported imported
__inline exported static
__inline__ exported static
extern inline imported exported
extern __inline imported static
extern __inline__ imported static
static inline static static
1.1.4 Writing inline assembly
Single assembly instructions and intrinsics
Green Hills MULTI supports the use of inline assembly code. This section provides
a brief overview of how inline assembly is used.
An assembly instruction can be inserted using the __asm or asm function. This
is shown in Example 1.2/
Example 1.2: Inline assembler using __asm
__asm ("nop");
Green Hills MULTI has supports a number of intrinsic functions which depend on
the target architecture. It is preferable to use these for simple operations as it is
4 RVS Integration Guide WF20190404 — Green Hills MULTI Integration Annex
Green Hills MULTI Green Hills MULTI
easier to interact with surrounding C code. Example 1.3 shows how to read from
a special purpose register using a Power Architecture intrinsic.
Example 1.3: Using intrinsic functions to read a special purpose register
t = __MFSPR(268);
Tip
The __DI() and __EI() intrinsics can be used to disable and enable in-
terrupts on multiple architectures.
Assembly macros
Green Hills MULTI has additionally implemented a function-like definition of as-
sembly macros that can more easily interact with C code.
Inside the macro, one or more storage mode templates must be specified for the
parameters. If the storage mode of the parameters match the storage mode of a
template then the associated instructions are executed.
Example 1.4 shows TriCore assembly for multiplying two values with just some of
the possible storage modes. As in this example, the % character of the first storage
mode must be in the first column of text.
Example 1.4: Green Hills MULTI assembly macro for TriCore
asm int asm_mult(x, y)
{
%dreg x %dreg y
mul d2, x, y
%dreg x %nearmem y
ld.w d0, y
mul d2, x, d0
%error
}
Some of the common storage mode specifiers are given in Table 1.2. The valid set
of storage modes is dependent upon the target. For example, the %dreg storage
mode used in Example 1.4 is specific to a TriCore data register.
For more information, see the Enhanced asm Macro Facility for C and C++ chap-
ter of the Green Hills MULTI Building Applications guide.
Table 1.2 Assembly macro parameter storage modes
Storage mode Description
%reg A compiler selected temporary register or C register variable.
%con A compile-time constant.
%mem Matches any allowed machine addressing mode.
RVS Integration Guide WF20190404 — Green Hills MULTI Integration Annex 5
Green Hills MULTI Green Hills MULTI
Storage mode Description
%nearmem A location in memory that can be accessed with a single-load
instruction.
%farmem A location in memory that cannot be accessed with a sin-
gle-load instruction.
%error Generates a compiler error. You can use this mode to flag er-
rors at compile time if no appropriate pattern exists for a set of
actual arguments.
Assembly functions and __asmleaf
An asm macro will be inserted inline into the object code generated by the com-
piler. The compiler will automatically select which registers to use and manage
saving and restoring of registers used by the macro.
When implementing an ipoint function in assembly that is more than 2 or 3 assem-
bly instructions long, it can be desirable to implement it as a function to reduce
variability of execution time and allow for more accurate deinstrumentation. This
can easily be achieved by wrapping a call to an asm macro in a C function.
On the Power PC architecture, the __asmleaf keyword can be used to indicate
than an assembly macro will only alter the return register (r3). This prevents the
compiler from generating code to save and restore other registers.
A particular use of the __asmleaf macro is for an assembly macro call wrapped
in a function where the function has no other statements. In this situation the com-
piler will already manage volatile registers for the function call so they may be
freely used. Example 1.5 shows a Power PC assembly function that reads a timer
and writes the data to a buffer. The ipoint Id is stored in register r3 since it was
passed to the function wrapping the assembly macro. Using this assumption pre-
vents the compiler from generating any additional instructions associated with a
macro parameter.
Example 1.5: Wrapping a call to an __asmleaf macro
__asmleaf void RVS_ASM_Ipoint()
{
mfspr r12, 268
slwi r10, r12, 12
lis r12, %hiadj(rvs_buffer_ptr)
lwz r11, %lo(rvs_buffer_ptr)(r12)
or r0, r10, r3
stw r0, 0(r11)
addi r0, r11, 4
stw r0, %lo(rvs_buffer_ptr)(r12)
}
void RVS_Ipoint(unsigned int I)
{
RVS_ASM_Ipoint();
}
6 RVS Integration Guide WF20190404 — Green Hills MULTI Integration Annex

181
docs-extracted/src/scov/RVS/integration_resources/reference/integration_annexes/Compilers/rvs-ig-compilers-tasking_classic_cc166.md Normal file
View file

@ -0,0 +1,181 @@
---
title: "Rvs Ig Compilers Tasking Classic Cc166"
source: "./src/scov/RVS/integration_resources/reference/integration_annexes/Compilers/rvs-ig-compilers-tasking_classic_cc166.pdf"
category: "src/scov/RVS/integration_resources/reference/integration_annexes/Compilers"
pages: 10
extracted: "2026-07-06T23:15:03.283920"
---
# Rvs Ig Compilers Tasking Classic Cc166
> Extracted from `./src/scov/RVS/integration_resources/reference/integration_annexes/Compilers/rvs-ig-compilers-tasking_classic_cc166.pdf` (10 pages).
> Figures, diagrams, and tables may not render accurately in plain text.
TASKING Classic cc166
Integration Annex
Version WF20190404
Disclaimer
The information, text, and graphics contained within this document are
provided for information purposes only by Rapita Systems Ltd. Rapita
Systems Ltd. does not warrant the accuracy or completeness of the
information, text, and other items contained in this document.
Copyright and Trademarks
All rights reserved. Information and images contained within this doc-
ument are copyright and the property of Rapita Systems Ltd. All trade-
marks are hereby acknowledged to be the properties of their respective
owners.
Acknowledgments
Rapita Systems' tools are built using AdaCore's GNAT Pro compiler.
Rapita Systems Ltd.
Registered in the UK, number 5011090.
Registered address:
Atlas House
Link Business Park
Osbaldwick Link Road
York
YO10 3JB
UK
Phone: +44 (0) 1904 413 945
http://www.rapitasystems.com/
This document copyright © 2019, Rapita Systems Ltd.
Document build 118520
ID: DOC/16076
1 cc166 compiler wrapper
This Integration Annex tells you how to install and configure the RVS TASKING
Classic cc166 compiler wrapper. This can be used with TASKING Embedded De-
velopment Environment (EDE) to preprocess and instrument source files as they
are compiled. This integration annex assumes TASKING classic EDE and cc166
version 8.9r1.
1.1 Integrating with EDE
This section gives you a guide on how to integrate RVS with EDE on Microsoft
Windows.
1.1.1 Installing the compiler wrapper
Run the Configure RVS Compiler Wrappers executable that came with the RVS
install.
Figure 1.1: Running Configure RVS Compiler Wrappers
Select to install the cc166 compiler wrapper and click next.
Figure 1.2: Selecting cc166 compiler wrapper
RVS Integration Guide WF20190404 TASKING Classic cc166 Integration Annex 3
Integrating with EDE cc166 compiler wrapper
Enter the folder in which cc166 is located and click next. The default folder is
C:\Program Files (x86)\TASKING\c166 v8.9r1\bin.
Figure 1.3: Choosing directory of cc166
Select to wrap the compiler and click next and then finish.
Figure 1.4: Wrapping the compiler
1.1.2 Setting up the build configuration
The next steps detail how to set up your project for instrumentation using the com-
piler wrapper.
You will need to have to hand your TASKING Classic cc166 compiler wrapper op-
tions. See Section 4.2 in the RVS Integration Guide for more information on con-
figuring compiler wrappers.
4 RVS Integration Guide WF20190404 TASKING Classic cc166 Integration Annex
cc166 compiler wrapper Integrating with EDE
Create a copy of your EDE .pjt project file in the same directory as the original.
Start EDE and open the copied project.
In the project view of EDE, right click the project and select Project Options.
Figure 1.5: Opening the Project Options window
In the Project Options window expand C-Compiler and click Miscellaneous. Then
in the Additional options field; enter your TASKING Classic cc166 compiler wrap-
per options. An example of these options can be see in Example 1.1.
RVS Integration Guide WF20190404 TASKING Classic cc166 Integration Annex 5
Integrating with EDE cc166 compiler wrapper
Figure 1.6: Adding compiler wrapper options
Example 1.1: Example TASKING Classic cc166 compiler wrapper options
-RVS=C:\example\rvs -RVSROOT=C:\RVS1.0 -RVSCOLLECTION=covmap
• -RVS=C:\example\rvs tells the compiler wrapper the integration folder is
located at C:\example\rvs.
• -RVSROOT=C:\RVS1.0 tells the compiler wrapper that RVS is installed
at C:\RVS1.0.
• -RVSCOLLECTION=covmap sets the instrumentation point collection
method to a coverage map.
In the Project Options window expand Linker/Locator and click Miscellaneous.
Then in the Additional command line options/controls field, enter your TASKING
Classic cc166 compiler wrapper options. Then click OK to accept the changes.
6 RVS Integration Guide WF20190404 TASKING Classic cc166 Integration Annex
cc166 compiler wrapper Integrating with EDE
Figure 1.7: Adding linker wrapper options
1.1.3 Running the integration
This section tells you how to run the instrumented build to obtain an instrumented
executable and structural report.
From the EDE toolbar select Build and click Clean from the menu. This will ensure
that the build system passes the compiler wrapper all the source filesin the project.
If you do not clean the project then some files may be skipped.
RVS Integration Guide WF20190404 TASKING Classic cc166 Integration Annex 7
Integrating with EDE cc166 compiler wrapper
Figure 1.8: Cleaning the project
From the EDE toolbar select Build and click Build from the menu.
8 RVS Integration Guide WF20190404 TASKING Classic cc166 Integration Annex
cc166 compiler wrapper Integrating with EDE
Figure 1.9: Building the project
The build should produce an executable containing instrumentation and a sta-
tic report file in the directory <integration_folder>/results named
project.rvd. The <integration_folder> is set by the -RVS option in the TASKING
Classic cc166 compiler wrapper options.
RVS Integration Guide WF20190404 TASKING Classic cc166 Integration Annex 9
This page intentionally left blank

264
docs-extracted/src/scov/RVS/integration_resources/reference/integration_annexes/Compilers/rvs-ig-compilers-tasking_vxtoolset.md Normal file
View file

@ -0,0 +1,264 @@
---
title: "Rvs Ig Compilers Tasking Vxtoolset"
source: "./src/scov/RVS/integration_resources/reference/integration_annexes/Compilers/rvs-ig-compilers-tasking_vxtoolset.pdf"
category: "src/scov/RVS/integration_resources/reference/integration_annexes/Compilers"
pages: 8
extracted: "2026-07-06T23:15:03.307429"
---
# Rvs Ig Compilers Tasking Vxtoolset
> Extracted from `./src/scov/RVS/integration_resources/reference/integration_annexes/Compilers/rvs-ig-compilers-tasking_vxtoolset.pdf` (8 pages).
> Figures, diagrams, and tables may not render accurately in plain text.
TASKING VX-toolset
Integration Annex
Version WF20190404
Disclaimer
The information, text, and graphics contained within this document are
provided for information purposes only by Rapita Systems Ltd. Rapita
Systems Ltd. does not warrant the accuracy or completeness of the
information, text, and other items contained in this document.
Copyright and Trademarks
All rights reserved. Information and images contained within this doc-
ument are copyright and the property of Rapita Systems Ltd. All trade-
marks are hereby acknowledged to be the properties of their respective
owners.
Acknowledgments
Rapita Systems' tools are built using AdaCore's GNAT Pro compiler.
Rapita Systems Ltd.
Registered in the UK, number 5011090.
Registered address:
Atlas House
Link Business Park
Osbaldwick Link Road
York
YO10 3JB
UK
Phone: +44 (0) 1904 413 945
http://www.rapitasystems.com/
This document copyright © 2019, Rapita Systems Ltd.
Document build 118520
ID: DOC/12013
1 TASKING VX-toolset
This Integration Annex contains information relevant to the TASKING VX-toolset
series of compilers. For information on using RVS with other TASKING develop-
ment tool-chains, please contact support@rapitasystems.com for an appropriate
Integration Annex for that tool-chain.
1.1 TASKING tools and options
Note
TASKING VX-toolset compilers are available for a number of different target
devices. The tool names are composed from a tool-specific part, followed
by a target-specific suffix. In this guide, the tool names are given in a gener-
ic form, for example cpXX represents the C++ compiler. To obtain the actu-
al tool name, substitute the suffix appropriately. For example, cppcp is the
tool name for the C++ compiler targeting TriCore-PCP devices.
The TASKING VX-toolset development environment consists of a number of differ-
ent executables that perform different parts of the development process. The tools
that are relevant to the RVS build integrations are:
C compiler - cXX.exe
Compiles C code into target-specific assembly language
C++ compiler - cpXX.exe
Compiles C++ code into target-specific assembly language
Control Program - ccXX.exe
Facilitates the invocation of the various components of the TASKING VX-toolset
from a single command line
Although it is recommended that the build tools should always be called through
the Control Program, it is possible to execute the compiler directly when using a
command line-based build environment. As the available options differ depending
on how the compiler is invoked, it will be necessary to examine the build process to
establish which method is in use, and which options are appropriate. The Eclipse
IDE supplied with the TASKING VX-toolset always makes use of the Control Pro-
gram in its build process.
When passing options to TASKING tools, most options and their associated flags
exist in both long and short forms. A lower-case letter or +longflag turns a flag
on, while an upper-case letter or -longflag turns it off.
RVS Integration Guide WF20190404 — TASKING VX-toolset Integration Annex 3
Preprocessing C/C++ TASKING VX-toolset
1.2 Preprocessing C/C++
The availability of some of these options depends on which compiler is used, and
also whether the compiler is called directly or through the Control Program.
Produce preprocessed source code:
-E or --preprocess
When using the Control Program ccXX.exe, preprocessed output for file.c
is automatically written to file.pre. When the C compiler (cXX.exe) or C++
compiler (cpXX.exe) are called directly, output is sent to stdout, but can be
directed to a file using the -o/--output option.
Produce preprocessed output and preserve comments:
-Ec or --preprocess=+comments
The c/comments flag, when active, produces preprocessed output with com-
ments included. The default is for comments to be excluded from the pre-
processed output.
Important
If annotations have been inserted into the source code using the formatted
comment syntax, comments must be preserved in the preprocessed out-
put.
Save preprocessed output in object directory while compiling
-E --no-preprocessing-only
Note
The --no-preprocessing-only option is supported by the Control
Program and the C++ compiler. It is not available when the C compiler
cXX.exe is executed directly.
By default, the source code is not compiled when the -E/--preprocess option
is selected. When this option is used with the Control Program, the compiler is
invoked twice - firstly to produce the preprocessed output, then a second time to
complete the build. Preprocessed output for <file>.c is automatically stored
in <file>.pre.
4 RVS Integration Guide WF20190404 — TASKING VX-toolset Integration Annex
TASKING VX-toolset Instrumenter Options
Warning
Beware of using these options.
Remove line marker modifiers
-Ep or --preprocess=+noline.
The p/noline flag, if active, will cause the preprocessed output to be gen-
erated without line markers. If line markers are not included, RVS will not be
able to display the original source code in the report.
Save temporary files.
-t without other preprocessing options (Control Program only).
This option, if used without other preprocessing options, will save pre-
processed output while compiling but the output does not include line
markers.
1.2.1 Examples
These examples use the TASKING VX-toolset C166 compiler, and assume that
it will be called through its Control Program cc166. The same options apply
to TASKING VX-toolset compilers for other processors using their corresponding
Control Programs, e.g. cctc for TriCore. Different options may be required if the
C or C++ compiler executable is invoked directly. For further information, see the
User Guide supplied with the TASKING VX-toolset development environment.
Example 1.1: Using TASKING VX-toolset to preprocess with comments
cc166 -E+comments path/source/x.c
Using this command, preprocessed output with comments will automatically be
written to a file named x.pre.
Example 1.2: Using TASKING VX-toolset to save preprocessed output in object
directory while compiling
cc166 -c -E+comments --no-preprocessing-only path/source/x.c -o path/
build/x.o
1.3 Instrumenter Options
Use the --cext TASKING option with cins for instrumenting C preprocessed
source code.
Use the --cext TASKING option with cppins for instrumenting C++ pre-
processed source code.
RVS Integration Guide WF20190404 — TASKING VX-toolset Integration Annex 5
Inlining an RVS_I function TASKING VX-toolset
1.4 Inlining an RVS_I function
If RVS_I is not written as a macro, it is recommended that it is defined as an inline
function within rvs_ipoint.h.
With TASKING VX-toolset, a function may be declared inline by using the inline
keyword in its declaration (Example 1.3).
Example 1.3: Declaring RVS_I as an inline function
inline void RVS_I(unsigned int I)
{
/* ipoint function code */
}
A function declared as inline will always be inlined by the compiler, regardless
of the state of any compiler optimization settings. Additionally, #pragma noin-
line will be overridden by an inline declaration.
1.5 Writing inline assembly
The C compiler supplied with the TASKING VX-toolset allows the insertion of inline
assembly using the __asm keyword. The general syntax of the __asm keyword is:
__asm( "instruction_template"
[ : output_param_list
[ : input_param_list
[ : register_save_list]]] );
instruction_template
List of assembly instructions, which may contain parameters from the output and
input parameter lists. Where a contiguous block of assembly instructions is re-
quired, multiple instructions should be inserted into a single __asm statement, as
compiler optimizations may insert additional instructions between __asm state-
ments.
output_param_list
List of C expressions corresponding to the output parameters of the assembly
section, and constraint values indicating the type of register to be used to store
each parameter. The compiler will assign appropriate registers for each parameter.
input_param_list
List of C expressions corresponding to the input parameters of the assembly sec-
tion, and constraint values indicating the type of register to be used to store each
parameter. The compiler will assign appropriate registers for each parameter.
register_save_list
A list of reserved registers which the assembly section should not alter. The com-
piler will not use these registers when assigning registers to parameters. Reserving
too many registers can result in insufficient registers being available for allocation.
6 RVS Integration Guide WF20190404 — TASKING VX-toolset Integration Annex
TASKING VX-toolset Writing inline assembly
The specific syntax of the __asm command and the format of register and para-
meter lists varies depending on the target architecture. For target-specific infor-
mation please see the relevant section in the TASKING VX-toolset User Guide sup-
plied with the development system.
RVS Integration Guide WF20190404 — TASKING VX-toolset Integration Annex 7
This page intentionally left blank

358
docs-extracted/src/scov/RVS/integration_resources/reference/integration_annexes/Compilers/rvs-ig-visualstudio.md Normal file
View file

@ -0,0 +1,358 @@
---
title: "Rvs Ig Visualstudio"
source: "./src/scov/RVS/integration_resources/reference/integration_annexes/Compilers/rvs-ig-visualstudio.pdf"
category: "src/scov/RVS/integration_resources/reference/integration_annexes/Compilers"
pages: 10
extracted: "2026-07-06T23:15:57.847307"
---
# Rvs Ig Visualstudio
> Extracted from `./src/scov/RVS/integration_resources/reference/integration_annexes/Compilers/rvs-ig-visualstudio.pdf` (10 pages).
> Figures, diagrams, and tables may not render accurately in plain text.
Visual Studio
Integration Annex
Version WF20190404
Disclaimer
The information, text, and graphics contained within this document are
provided for information purposes only by Rapita Systems Ltd. Rapita
Systems Ltd. does not warrant the accuracy or completeness of the
information, text, and other items contained in this document.
Copyright and Trademarks
All rights reserved. Information and images contained within this doc-
ument are copyright and the property of Rapita Systems Ltd. All trade-
marks are hereby acknowledged to be the properties of their respective
owners.
Acknowledgments
Rapita Systems' tools are built using AdaCore's GNAT Pro compiler.
Rapita Systems Ltd.
Registered in the UK, number 5011090.
Registered address:
Atlas House
Link Business Park
Osbaldwick Link Road
York
YO10 3JB
UK
Phone: +44 (0) 1904 413 945
http://www.rapitasystems.com/
This document copyright © 2019, Rapita Systems Ltd.
Document build 118520
ID: DOC/18071
1 Visual Studio
This Integration Annex contains information to help you integrate RVS with Visual
Studio.
To integrate RVS with Visual Studio, you need to wrap the Visual Studio compilers.
When you have done this, you can either run RVS from the RVS Project Manager
or configure Visual Studio so that it can run the RVS tools directly.
This is described in the sections below:
1. Section 1.1: Initial project setup describes how to set up an initial RVS project
so that it is ready for integration with Visual Studio.
2. Section 1.2: Wrapping Visual Studio compilers describes how to wrap Visual
Studio compilers.
3. Section 1.3: Setting RVS up to run in Visual Studio describes how to configure
Visual Studio so you can run RVS from it.
For support and advice on integration issues, or for more information
on integrating RVS, please contact the Rapita Systems support team at
support@rapitasystems.com.
1.1 Initial project setup
To setup an RVS project, follow the Getting Started steps as described in the RVS
Integration Guide.
The build system for Visual Studio projects is msbuild so a typical Visual Studio
project will use the following commands:
Table 1.1 RVS settings for external tools
RVS Stage msbuild command
Clean msbuild.exe /t:Clean solutionName.sln
Prepare msbuild.exe /t:Build solutionName.sln
Build msbuild.exe /t:Build solutionName.sln
These can be added into the RVS project and modified as needed.
Once an RVS project has been created, you will need to wrap the compiler that
you are using. This is done through one of two methods described in the sections
below.
RVS Integration Guide WF20190404 — Visual Studio Integration Annex 3
Wrapping Visual Studio compilers Visual Studio
1.2 Wrapping Visual Studio compilers
Before you can use RVS in a Visual Studio project, you need to wrap the Visual
Studio compilers and linkers used to build your code. You can wrap Visual Studio
compilers through the following methods:
• In-place wrapping. This is the recommended option, but is not always possi-
ble, and involves renaming Visual Studio compilers and replacing them with
RVS compiler wrappers, see Section 1.2.1: Wrapping in-place.
• Specifying the path to wrappers in your RVS project, see Section 1.2.2: Spec-
ifying the path to wrappers in an RVS project.
Note that this method cannot be used to wrap compilers from Visual Studio
versions prior to Visual Studio 2008.
1.2.1 Wrapping in-place
To wrap a Visual Studio compiler in-place, use the Configure RVS Compiler Wrap-
pers utility as described in the RVS Integration Guide.
1.2.2 Specifying the path to wrappers in an RVS project
Important
This method cannot be used to wrap compilers from Visual Studio versions
prior to Visual Studio 2008.
In order to specify a path for the compiler wrappers to use in your RVS project, you
must modify your RVS project configuration to point msbuild at the RVS compiler
wrapper executable, and point the RVS compiler wrapper executable at the original
compiler. The RVS project configuration changes required to do this are detailed
below.
You can wrap the Visual Studio compilers by specifying the path to them in your
RVS project by doing the following:
1. Open your project in the RVS Project Manager.
2. Click Configure on the project overview page to open the RVS Config Editor.
3. Open the Compiler Wrapper page for the Target you are using – this
is nested under Targets.
4. Configure the RVS wrapper for the Visual Studio compiler:
a. Click Add beside the list of compiler wrappers assigned to your target.
b. In the Wrapper Path field, type cl_wrap.
c. In the Original Tool Path field, click on Browse, select the cl.exe file
in your Visual Studio install path and click Open.
d. Click OK to add the wrapper to your target.
4 RVS Integration Guide WF20190404 — Visual Studio Integration Annex
Visual Studio Setting RVS up to run in Visual Studio
5. Configure the RVS wrapper for the Visual Studio linker:
• Click Add beside the list of compiler wrappers assigned to your target.
• In the Wrapper Path field, type link_wrap.
• In the Original Tool Path field, click on Browse, select the link.exe file
in your Visual Studio install path and click Open.
• Click OK to add the wrapper to your target.
6. Open the Command Line page for your Target.
7. Configure the RVS tools to run your Visual Studio compiler and linker through
the RVS compiler and linker wrappers:
• In the Prepare Command field, append the following arguments:
/p:CLToolExe=cl_wrap.exe /p:CLToolPath=${{wrapper-scripts-
folder}}\visual_studio /p:LinkToolExe=link_wrap.exe /
p:LinkToolPath=${{wrapper-scripts-folder}}\visual_studio
• Append the same arguments in the Build Command field.
8. Save and Close your changes using the buttons at the top-left of the
RVS Config Editor.
Note
The command line argument you entered for the RVS Prepare and Build
Commands means the following:
• /p:CLToolExe=cl_wrap.exe tells msbuild which compiler to use
instead of the default cl.exe.
• /p:CLToolPath=${{wrapper-scripts-folder}}
\visual_studio tells msbuild the location of CLToolExe, the
compiler executable (${{wrapper-scripts-folder}} is an RVS
variable that expands to the directory in your RVS installation which con-
tains the provided compiler wrappers for the RVS Project Manager).
• /p:LinkToolExe and
/p:LinkToolPath=${{wrapper-scripts-folder}}
\visual_studio perform the same functions as the above argu-
ments, but for the linker rather than the compiler.
1.3 Setting RVS up to run in Visual Studio
You can integrate RVS with Visual Studio such that you can run RVS directly from
within the Visual Studio IDE. To do so, you must add External Tools to your Visual
Studio project's environment settings for the RVS integration stages that you want
to run from Visual Studio.
There are two methods to do this:
RVS Integration Guide WF20190404 — Visual Studio Integration Annex 5
Setting RVS up to run in Visual Studio Visual Studio
• If your Visual Studio installation only uses the default External Tools (Create
GUID and Error Lookup in 2017, or just Error Lookup in 2015), and you have
not modified your Toolbars from the default settings, you can replace your
project's environment settings using a file included in your RVS installation as
described in Section 1.3.1: Replacing the Visual Studio external tools list. This is
typically the easier of the two methods but following this method will overwrite
your current Visual Studio External Tools and Toolbar settings so it is important
to ensure that you only have the defaults in use.
• If your Visual Studio installation uses External Tools in addition to the defaults
listed above or if you have customized your Toolbars, you must manually add
settings for each of the RVS integration stages that you want to run from Visual
Studio to your Visual Studio project's environment settings as described in
Section 1.3.2: Manually adding RVS tools to your project.
Important
Both methods require that your RVS project is stored in the same directory
as your Visual Studio solution file.
Important
Both methods require that the RVS_PATH system variable has been set
and points to the RVS tool directory. This should have been set when you
installed RVS.
1.3.1 Replacing the Visual Studio external tools list
Warning
Files for importing the vssettings into Visual Studio 2017 and Visual Studio
2015 are provided, for other versions or if the settings import step doesn't
work then you may need to follow the manual steps instead.
Warning
You should not use this method to import RVS tool settings if your Visu-
al Studio installation has External Tools other than the defaults since this
method will overwrite them.
Warning
You should not use this method to import RVS toolbar settings if your Visual
Studio installation has Toolbars other than the defaults since this method will
overwrite them.
6 RVS Integration Guide WF20190404 — Visual Studio Integration Annex
Visual Studio Setting RVS up to run in Visual Studio
To replace your Visual Studio project's environment settings, do the following:
1. In Visual Studio, open the Tools menu, and select Import and Export Set-
tings.
2. Select Import selected environment settings and click Next.
3. If you want to, make a backup of your current settings file by selecting Yes,
save my current settings, choose an appropriate name and location for
your settings backup file, then click Next.
4. Your RVS install includes environment settings files for Visual Studio 2015
and 2017 that configure Visual Studio to run RVS tools directly. These are
located in
%RVS_PATH%\integration_resources\plugins\ide\visual_studio\
as vs<version>_toolbar.vssettings, where <version> is your
Visual Studio version number (year), e.g. 2017. Click Browse, select this
file, then click Next.
5. Expand All Settings » General Settings in the tree on the left hand side of the
Import and Export Settings Wizard window and ensure that External Tools
List and Menu and Command Bar Customizations are both selected.
6. Click Finish, then Close.
After following these steps, you should see a new drop-down menu called RVS
on the Visual Studio toolbar from which you can run RVS integration stages on
your open solution.
1.3.2 Manually adding RVS tools to your project
To add to your Visual Studio project's environment settings, you must do the fol-
lowing:
1. Add External Tools for the stages of an RVS integration that you want to run
from Visual Studio.
2. Add toolbars to run the External Tools you added.
After doing so, you can run RVS tools from the Visual Studio toolbar.
Adding RVS external tools
To add External Tools to your Visual Studio project, do the following:
1. In Visual Studio, open the Tools menu and select External Tools.
2. Click Add to add a new tool.
3. Enter the settings for the RVS stages you want to add to your Visual Studio
project; for each stage:
• Set the Title and Arguments settings as specified in Table 1.2 below.
• Set the Command setting to:
%RVS_PATH%\integration_resources\plugins\ide\visual_studio
\rvsdriver_vs_wrapper.bat
RVS Integration Guide WF20190404 — Visual Studio Integration Annex 7
Setting RVS up to run in Visual Studio Visual Studio
• Set the Initial Directory setting to $(SolutionDir).
• Set the Use Output Window setting to Yes.
4. Apply your changes and click OK to close the External Tools window.
Table 1.2 RVS settings for external tools
Title Arguments
RVS Clean $(SolutionDir) --clean
RVS Prepare $(SolutionDir) --prepare
RVS Build $(SolutionDir) --build
RVS Run $(SolutionDir) --run
RVS Report $(SolutionDir) --report
Adding toolbars to run RVS external tools
To add toolbars to run RVS integration stages from your Visual Studio project, do
the following:
1. Open the Tools menu and click Customize.
2. In the Toolbars tab, click New.
3. In the Toolbar name field, enter RVS Instrumentation (or some other
appropriate name).
4. Open the Commands tab and click the Toolbar button.
5. Open the Toolbar drop-down menu and select the toolbar you made in the
previous steps.
6. Click Add New Menu, then Modify Selection.
7. In the Name field, enter RVS (or some other appropriate name).
8. Click OK to close the Modify Selection window.
9. Open the Toolbar drop-down menu and select the menu you just created
(e.g. RVS Instrumentation | RVS).
10. Click Add Command....
11. In the Categories section left of the Add Command window, locate and select
the Tools entry.
12. In the Commands section right of the Add Command window, locate the Ex-
ternal Commands entries.
13. These are numbered in the order that they are listed in the External Tools
window, the first entry in that list will be External Command 1, the second
will be External Command 2 etc.
14. Add the External Commands for each of the integration stages you added to
your Visual Studio project. the RVS Clean command you made previous-
8 RVS Integration Guide WF20190404 — Visual Studio Integration Annex
Visual Studio Setting RVS up to run in Visual Studio
ly, select it, and click OK to add it to your toolbar. The name in the toolbar
settings will display as External Command 2 but on the toolbar it will
display the names from the External Commands entries.
Running RVS External Tools
After configuring RVS external tools and adding them to your toolbar, you can run
the RVS stages from the RVS drop-down menu on the Visual Studio toolbar.
RVS Integration Guide WF20190404 — Visual Studio Integration Annex 9
This page intentionally left blank

170
docs-extracted/src/scov/RVS/integration_resources/reference/integration_annexes/Cpus/rvs-ig-cpus-armsim.md Normal file
View file

@ -0,0 +1,170 @@
---
title: "Rvs Ig Cpus Armsim"
source: "./src/scov/RVS/integration_resources/reference/integration_annexes/Cpus/rvs-ig-cpus-armsim.pdf"
category: "src/scov/RVS/integration_resources/reference/integration_annexes/Cpus"
pages: 6
extracted: "2026-07-06T23:14:24.273191"
---
# Rvs Ig Cpus Armsim
> Extracted from `./src/scov/RVS/integration_resources/reference/integration_annexes/Cpus/rvs-ig-cpus-armsim.pdf` (6 pages).
> Figures, diagrams, and tables may not render accurately in plain text.
ARMSim
Integration Annex
Version WF20190404
Disclaimer
The information, text, and graphics contained within this document are
provided for information purposes only by Rapita Systems Ltd. Rapita
Systems Ltd. does not warrant the accuracy or completeness of the
information, text, and other items contained in this document.
Copyright and Trademarks
All rights reserved. Information and images contained within this doc-
ument are copyright and the property of Rapita Systems Ltd. All trade-
marks are hereby acknowledged to be the properties of their respective
owners.
Acknowledgments
Rapita Systems' tools are built using AdaCore's GNAT Pro compiler.
Rapita Systems Ltd.
Registered in the UK, number 5011090.
Registered address:
Atlas House
Link Business Park
Osbaldwick Link Road
York
YO10 3JB
UK
Phone: +44 (0) 1904 413 945
http://www.rapitasystems.com/
This document copyright © 2019, Rapita Systems Ltd.
Document build 118520
ID: DOC/12030
1 ARMSim
This Integration Annex contains information to assist in the integration of RVS with
the ARMSim simulator, which is provided with the RVS examples.
The information and examples in this guide are taken from the sample integration
for the ARMSim simulator, which is installed with the RVS software. The source files
for the sample integration can be found in <RVSROOT>/TIKs/armsim (where
<RVSROOT> is the directory in which RVS is installed).
For support and advice on integration issues, or for more information on integrat-
ing RVS with other targets, please contact the Rapita Systems support team at
support@rapitasystems.com.
1.1 Obtaining a timestamp
A timestamp can be retrieved by a task running on the simulated CPU by reading
the value from address 0. The timestamp value is returned as a 32-bit integer.
1.2 Writing to the output port
The ARMSim simulator is configured with a 32-bit wide output port located at ad-
dress 0. The simulator automatically logs all data written to this port to a text file
output_port on the host machine. The output data is automatically appended
with a timestamp by the output mechanism.
1.2.1 Implementing RVS_I
The output port described above can be used to implement RVS_I. A sample
implementation is shown in Example 1.1.
Example 1.1: ARMSim example RVS_I implementation
...
void RVS_I( unsigned long I );
#define RVS_I( I ) (void)( *(volatile unsigned long *)0 = (I))
...
1.2.2 Implementing RVS_Output
The output port at address 0 can also be used where the RVS_Output function
is required to output coverage information which is stored in an in-memory map.
An example implementation of RVS_Output, which writes the contents of the
map buffer out through the output port, can be seen in Example 1.2.
RVS Integration Guide WF20190404 — ARMSim Integration Annex 3
Writing to the output port ARMSim
Example 1.2: ARMSim example RVS_Output implementation
...
#define WRITE_OUTPUT( I ) (void)( *(volatile unsigned long *)0 = (I))
#define WRITE(A,B) (WRITE_OUTPUT(A), WRITE_OUTPUT(B))
void RVS_Output (void)
{
unsigned int i;
for (i=0; i<RVS_HEADER_SIZE; i++)
{
WRITE ( rvs_info_data[i], 1 );
}
/* Output Coverage */
for (i=0;i<RVS_COV_SIZE;i++)
{
if (rvs_coverage_data[i])
{
WRITE ( i, rvs_coverage_data[i] );
}
unsigned int j,n;
n = rvs_static_mcdc[i].nb_bytes;
if (n != 0)
{
for (j=0;j<n;j++)
{
WRITE ( i, rvs_static_mcdc[i].mcdc[j] );
}
}
}
/* Clear all data after output */
rvs_coverage_reset();
}
...
Note
The map data consists of a list of visited ipoints. The output port mecha-
nism will add timestamps to these values as they are output, producing a
series of ipoint/timestamp pairs in the resulting output file. The timestamps
are not required for the purposes of calculating coverage metrics, and are
automatically disregarded by the covparser tool.
Important
When the output port is used to output map data in this way, the timestamp
values are not suitable for timing analysis using RapiTime.
4 RVS Integration Guide WF20190404 — ARMSim Integration Annex
ARMSim Data download and processing
1.3 Data download and processing
The output_port file is formatted such that it can be processed by the
timeparser or covparser tools to give timing or coverage data. Alternatively, the
traceutils utility can be used to convert the trace into an RPZ before processing it.
Important
Before the file can be processed or converted, it must be renamed with a
.txt extension, otherwise timeparser, covparser and traceutils will not
be able to establish that the file contains a trace in plain text format.
RVS Integration Guide WF20190404 — ARMSim Integration Annex 5
This page intentionally left blank

512
docs-extracted/src/scov/RVS/integration_resources/reference/integration_annexes/Cpus/rvs-ig-cpus-c166.md Normal file
View file

@ -0,0 +1,512 @@
---
title: "Rvs Ig Cpus C166"
source: "./src/scov/RVS/integration_resources/reference/integration_annexes/Cpus/rvs-ig-cpus-c166.pdf"
category: "src/scov/RVS/integration_resources/reference/integration_annexes/Cpus"
pages: 12
extracted: "2026-07-06T23:14:24.298669"
---
# Rvs Ig Cpus C166
> Extracted from `./src/scov/RVS/integration_resources/reference/integration_annexes/Cpus/rvs-ig-cpus-c166.pdf` (12 pages).
> Figures, diagrams, and tables may not render accurately in plain text.
C166/ST10
Integration Annex
Version WF20190404
Disclaimer
The information, text, and graphics contained within this document are
provided for information purposes only by Rapita Systems Ltd. Rapita
Systems Ltd. does not warrant the accuracy or completeness of the
information, text, and other items contained in this document.
Copyright and Trademarks
All rights reserved. Information and images contained within this doc-
ument are copyright and the property of Rapita Systems Ltd. All trade-
marks are hereby acknowledged to be the properties of their respective
owners.
Acknowledgments
Rapita Systems' tools are built using AdaCore's GNAT Pro compiler.
Rapita Systems Ltd.
Registered in the UK, number 5011090.
Registered address:
Atlas House
Link Business Park
Osbaldwick Link Road
York
YO10 3JB
UK
Phone: +44 (0) 1904 413 945
http://www.rapitasystems.com/
This document copyright © 2019, Rapita Systems Ltd.
Document build 118520
ID: DOC/12011
1 C166/ST10
This Integration Annex contains information to assist in the integration of RVS with
a target based on the C166/ST10 architecture.
The information and examples in this guide are primarily intended for users of
Infineon's XC166 (fourth generation) and XC2000 (fifth generation) families of 16-
bit embedded microcontroller for industrial and automotive applications, but may
also be relevant to users of older Infineon C166-based devices and the ST10 family
from STMicroelectronics.
For support and advice on integration issues, or for more information on integrat-
ing RVS with other targets, please contact the Rapita Systems support team at
support@rapitasystems.com.
Note
This Integration Annex refers to peripherals and control registers using the
names that are used by Infineon in the XC166 and XC2000 User Guides.
Devices and documentation produced by other vendors may use different
names.
Compilers that are commonly used with C166/ST10-derived devices, in-
cluding those produced by TASKING and Keil, include definitions to con-
vert register names into address values, without the requirement to use raw
address values in the source code. The C examples given in this guide as-
sume that such compiler definitions are in use.
Actual address values for specific control registers, along with further infor-
mation about the use of on-chip peripherals in a particular device, can be
found in that device's User Guide.
1.1 Obtaining a timestamp
All devices in the XE166 and XC2000 family contain a general-purpose timer (GPT)
unit, providing five timers (numbered T2-T6) in two blocks. When the timer clock
is driven at the same speed as the processor clock the maximum available timer
resolution is two CPU clock cycles (GPT block 2, timers T5 and T6) or four CPU
clock cycles (GPT block 1, timers T2, T3 and T4).
Three registers are associated with each individual timer:
• GPT12E_Tx: data register for timer x, can be read to obtain current timer
value.
• GPT12E_TxCON: control register for timer x.
RVS Integration Guide WF20190404 — C166/ST10 Integration Annex 3
Obtaining a timestamp C166/ST10
• GPT12E_TxIC: interrupt register for timer x, a flag will be set in this register
when a timer under/overflow occurs.
The timer must be configured and enabled before it can be used. The timer initial-
ization code should be included in the RVS_Init() routine. It is recommended
that one of the GPT block 2 timers (either T5 or T6) be used if available, as these
offer the highest available level of precision.
Example 1.1 shows the code necessary to configure and enable the timer T5 with
two-cycle precision. For further details about the use of general-purpose timers
on a specific device, refer to the relevant section in the user guide.
Example 1.1: Initialization code for timer T5
...
/* Enable timer module GPT2 */
GPT12E_KSCCFG = 0x0003; /* Module Enable */
_nop(); // one cycle delay
_nop(); // one cycle delay
/* Configure T5 as timer, counting up, starting value 0x0000 */
GPT12E_T5CON = 0x0000; /* load timer 5 control register */
GPT12E_T5 = 0x0000; /* load timer 5 register */
/* Start T5 */
GPT12E_T5CON_T5R = 1; /* set timer 5 run bit */
...
Note
In addition to the general purpose timer units, XE166 and XC2000 devices
also contain a real-time clock (RTC) unit. This is normally clocked from an
external oscillator at a frequency that is considerably lower than the proces-
sor clock. As a result, the RTC does not normally offer adequate precision
for cycle-level timing measurement.
Once the timer is configured, its value can be read directly from within the instru-
mentation point code, where an in-memory or file system trace is used (it is not
normally necessary to read an on-chip timestamp where data is collected through
an I/O port using an RTBx or a logic analyzer). Example 1.2 shows a possible im-
plementation of an instrumentation point routine, which stores a 4-bit ID and a 12-
bit timestamp as a 16-bit value in an in-memory trace.
4 RVS Integration Guide WF20190404 — C166/ST10 Integration Annex
C166/ST10 Writing to an output port
Example 1.2: Using a timestamp in RVS_Ipoint
...
void RVS_Ipoint( RVS_Ipoint_Type id )
{
unsigned short timestamp;
timestamp = GPT12E_T5;
/* Check whether trace buffer has space available */
if( ++RVS_Ipoint_Idx < RVS_TRACE_LEN )
{
/* Timer is scaled down so that
* the low 12 bits are the required 12 bits.
* This saves on masking code at run-time.
*/
RVS_Array[RVS_Ipoint_Idx].I_T = (timestamp << 4) | id;
}
else
{
/* No protection from interrupt required */
RVS_Ipoint_Idx = RVS_TRACE_LEN-1;
}
}
...
1.2 Writing to an output port
The XE166 and XC2000 family of devices provide a set of general purpose IO
ports which can be accessed from the CPU and peripheral devices. The available
ports vary depending on the exact device in use, for details regarding the available
output ports on a specific device, refer to the appropriate section of the device
user guide.
For maximum flexibility, physical pins are shared between a number of functions,
and must be assigned appropriately in software before they can be used. Pins
within a GPIO port can be configured individually using the port control register
associated with each specific pin (Px_IOCRnn, where x denotes the associated
port and nn identifies the pin). In this way it is possible to use only a subset of the
pins associated with a GPIO port if physical pins are required for other functions,
or where the number of pins required is less than the total provided by the port.
The output characteristics of GPIO pins can be set using the port output control
register (Px_POCON, where x identifies the associated port). A single register for
each port allows the output characteristics to be set in four-pin groups.
When using an external logic analyzer or RTBx to collect trace data from a GPIO
port, it is recommended that the output characteristics be configured as a strong
driver with sharp edges to allow the output of data at the maximum possible rate.
Further information about port output characteristics, including electrical specifi-
cations and timings, can be found in Infineon Application Note AP16120.
Example 1.3 shows the code required to enable the pins associated with GPIO
port 0 as outputs, and to set the electrical characteristics to strong driver mode
with sharp edges.
RVS Integration Guide WF20190404 — C166/ST10 Integration Annex 5
Bit flipping method C166/ST10
Example 1.3: Initialization code for GPIO port 0
...
//--------------------------------------------------------
// Configuration of Port P0:
// -------------------------------------------------------
// P0.0 - P0.7 used as general purpose output
// - push/pull output is selected, pin status is low level
// P0.0 - P0.7 output driver characteristic: strong driver
// P0.0 - P0.7 output edge characteristic: sharp edge mode
P0_IOCR00 = 0x0080; // load port control register 0
P0_IOCR01 = 0x0080; // load port control register 1
P0_IOCR02 = 0x0080; // load port control register 2
P0_IOCR03 = 0x0080; // load port control register 3
P0_IOCR04 = 0x0080; // load port control register 4
P0_IOCR05 = 0x0080; // load port control register 5
P0_IOCR06 = 0x0080; // load port control register 6
P0_IOCR07 = 0x0080; // load port control register 7
P0_POCON = 0x0000; // strong driver, sharp edge
...
Once the port has been configured, values can be output by writing to the port
output address (Px_OUT, where x denotes the port ID), either directly from C or
by using inline assembly code. Example 1.4 shows an example macro definition
for RVS_Ipoint which outputs data through an output port.
Example 1.4: RVS_Ipoint macro using an output port
...
//Port 1 output address: 0xFFA4
#define RVS_Ipoint(val) ( *(volatile unsigned int *)0xFFA4 = (val) )
...
As well as writing a value to an output port, individual bits can be set, cleared or
toggled using the port output modification register Px_OMRL. Ports greater than
8 bits in size have two port output modification registers: Px_OMRL controls the
least significant 8 bits, and a second register Px_OMRH controls the remaining
bits. This allows a specific bit (or group of bits) to be set, cleared or toggled while
preserving the state of the remaining bits, with no need to read back the port output
register value.
1.3 Bit flipping method
In certain circumstances, data integrity problems have been encountered when
collecting trace data from XE166/XC2000 output ports. The bit-flipping method, as
described in this section, is one possible way by which data errors can be reduced
in these situations.
When using the bit-flipping method, instead of outputting the instrumentation point
identifiers directly, each identifier is encoded as a sequence of bit-flips. Using this
method produces a trace where only a single bit changes between consecutive
trace entries (i.e. the trace is a Gray code sequence). This knowledge can be used
6 RVS Integration Guide WF20190404 — C166/ST10 Integration Annex
C166/ST10 Bit flipping method
to validate the trace as it is decoded during trace processing. Errors in the trace
data can be detected, and then either flagged or worked around.
The bit-flipping method significantly reduces the number of instrumentation point
IDs that can be represented with a single write - using 8 output bits, only 8 distinct
identifiers can be represented, as opposed to the 256 identifiers that can be en-
coded if standard binary representation is used. It is therefore necessary to use a
sequence of writes to provide enough identifiers to instrument a typical application.
Typically, one output bit is used to denote the start of a multiple-write sequence,
the result of which identifies a 'long ipoint', with the remainder being available to
identify 'short ipoints' that require only a single write. The traceutils utility must be
used in conjunction with an appropriate trace filter to decode the ipoint sequence
from the generated trace data.
To keep these sequences as short as possible, the bit-flipping method is usually
used in conjunction with IdPack, which minimizes the total number of identifiers
required for instrumentation. As well as reducing the total number of identifiers
required, IdPack can also be configured to make the maximum use of 'short' ipoints
in the instrumentation, helping to reduce the timing overhead associated with the
instrumentation by decreasing the number of multiple writes required.
Example 1.5 shows a configuration file that can be used with an 8-bit output port.
Ipoint IDs 1-7 are defined as short ipoints. The ipoints in the range 220-559 will be
encoded as long ipoints. Any other ipoints will not be remapped by IdPack.
Example 1.5: Example IdPack configuration file
[group short]
range = [1..7]
name="Short"
[group long]
range = [220..559]
name="Long"
uniq_ids = TRUE
[group noremap]
range = [560..65535]
name="NOT_REMAPPED"
The encoded trace must be decoded before it can be parsed by timeparser or
covparser. The decoding process requires a number of different stages to convert
the collected trace data into the RPZ format used by the RVS tools:
1. The Gray coding must be decoded, to produce a series of values which
indicate the position of the bit that changed at each point in the trace. This
can be accomplished using the traceutils tool's built-in gray filter. When the
Gray coding has been removed, the binary value 00000001 encodes ID 1,
00000010 encodes ID 2, etc.
2. The bit-position representation of the trace values must be converted into an
integer representation. traceutils provides the bit_pos filter for this pur-
pose.
RVS Integration Guide WF20190404 — C166/ST10 Integration Annex 7
Bit flipping method C166/ST10
3. The trace now contains a mixture of short ipoints (IDs 1-7) and encoded long
ipoints (a sequence of four values, the first of which is ID 8). The sequences
which make up the long ipoint IDs must now be decoded to produce a sin-
gle trace entry for each ipoint. This operation requires the use of traceutils'
advanced python-based filter syntax. Example 1.6 shows an example of how
such a filter might be written.
Note
These examples assume that a single task is instrumented, without the
need to process context switches or interrupts in the trace data. Addition-
al filtering stages will be necessary when analyzing systems where multiple
tasks or interrupts are present.
Note
For more information on trace filters, see Chapter 6 in the RVS Integration
Guide.
Example 1.6: Example python trace concatenation filter
<python_script>
base = 7
seq_len = 3
offset = 217
marker = base + 1
while True:
(eot, id, t, wt) = get()
if eot: # Exit if end of trace
break
if id != marker: # Short ipoint
put (id, t, wt) # Output ipoint value
else: # ID indicates start of
id = 0 # long ipoint sequence
for i in range(seq_len): # Retrieve 3 ipoints
(eot, j, s, ws) = get()
if eot: # Exit if end of trace
break
id = (id * base) + (j-1) # Compute encoded ID
if not eot:
id = id + offset # Add offset to ID
put (id, t, wt) # Output ipoint value
</python_script>
If required, Rapita Systems Ltd. can provide a set of integration scripts to auto-
matically generate configuration files, instrumentation point functions and filters
8 RVS Integration Guide WF20190404 — C166/ST10 Integration Annex
C166/ST10 Thread-safe instrumentation
which implement the bit-flipping method and ensure consistency across the in-
tegration. For further information, contact the Rapita Systems support team at
support@rapitasystems.com.
1.4 Thread-safe instrumentation
Where interrupts are present and enabled in the system, it is important to ensure
that the instrumentation point routine is protected against interrupts. This applies
particularly where in-memory tracing is used, or where the multiple values are writ-
ten to an output port to denote a single instrumentation point (e.g when using the
bit-flipping method described in Section 1.3).
The C166 architecture supports the software control of interrupts by changing the
value of the IEN bit in the PSW register. If this bit is set to zero, interrupts are
disabled. An instrumentation point routine can save the value of IEN, set it to
zero for the duration of the routine, then restore the value when the routine has
completed.
Note
Setting IEN to zero prevents any new interrupt requests from being accept-
ed by the CPU. However any preexisting requests which are already present
in the pipeline will be executed. To ensure that a block of code is not inter-
rupted, it is necessary to flush the pipeline with NOP instructions after hav-
ing disabled interrupts.
Example 1.7 shows how the IEN bit can be used to disable interrupts as part of
a larger instrumentation point routine.
Example 1.7: Using IEN to disable interrupts
...
/* save state of IEN and disable interrupts */
_bit saved_IEN = IEN;
IEN = 0;
/* flush pipeline with NOPs to ensure no interrupts */
_nop( );
_nop( );
_nop( );
/* start non-interruptible code */
...
/* end non-interruptible code */
/* restore state of IEN */
IEN = saved_IEN;
...
As well as being able to disable interrupts via the IEN bit, from the second gen-
eration onwards (i.e. C165 and C167 based devices) the C166 architecture also
supports the use of atomic instruction sections. The ATOMIC CPU instruction is
RVS Integration Guide WF20190404 — C166/ST10 Integration Annex 9
Thread-safe instrumentation C166/ST10
used to indicate that the next block of up to four instructions must be executed
atomically, and for the duration of their execution, interrupts are disabled.
The ATOMIC instruction takes effect immediately. There is no need to flush the
pipeline with NOP instructions as is necessary when disabling interrupts using the
IEN bit.
There are no restrictions on the type of instruction that can be incorporated inside
an atomic section. Instructions which incorporate hold states or have an execu-
tion time greater than one clock cycle are regarded as single instructions for the
purposes of the atomic section. Example 1.8 shows a section of inline assembly
code which uses the ATOMIC instruction to prevent a section of code from being
interrupted.
Example 1.8: Use of ATOMIC instruction in inline assembly
static inline void RVSI_LONG_0() {
__asm( "\tMOVW r11,#0x8080\n"
"\tMOVW r12,#0x101\n"
"\tATOMIC #4\n" /* next 4 instructions are atomic */
"\tMOVW 0xe9c4,r11\n"
"\tMOVW 0xe9c4,r12\n"
"\tMOVW 0xe9c4,r12\n"
"\tMOVW 0xe9c4,r12\n"
:
:
: "r11", "r12"
);
}
Although the maximum number of instructions which can be contained within an
atomic section is four, it is possible for one of those instructions to be a further
ATOMIC instruction. If this is the case, the ATOMIC instruction counter will be
reloaded with the new value: in this way, it is possible to combine multiple ATOMIC
instructions to produce longer uninterruptible instruction sequences. Example 1.9
shows how this method can be used to create a larger uninterruptible section of
code.
Example 1.9: Combining ATOMIC instructions to produce a longer atomic section
static inline void RVSI_LONG_1() {
__asm( "\tMOVW r11,#0x8080\n"
"\tMOVW r12,#0x101\n"
"\tATOMIC #4\n" /* next 4 instructions are atomic */
"\tMOVW 0xe9c4,r11\n"
"\tMOVW 0xe9c4,r12\n"
"\tMOVW 0xe9c4,r12\n"
"\tATOMIC #2\n" /* increase atomic section length */
"\tMOVW r11,#0x202\n"
"\tMOVW 0xe9c4,r11\n"
:
:
: "r11", "r12"
);
}
10 RVS Integration Guide WF20190404 — C166/ST10 Integration Annex
C166/ST10 Thread-safe instrumentation
Interrupt handling is automatically enabled at the completion of an atomic section.
Any interrupt requests raised during the execution of the atomic section will be
executed immediately following the last instruction in the atomic section.
Important
The use of long atomic code sequences may cause an increase in the inter-
rupt response time of a system.
RVS Integration Guide WF20190404 — C166/ST10 Integration Annex 11
This page intentionally left blank

466
docs-extracted/src/scov/RVS/integration_resources/reference/integration_annexes/Cpus/rvs-ig-cpus-powerpc.md Normal file
View file

@ -0,0 +1,466 @@
---
title: "Rvs Ig Cpus Powerpc"
source: "./src/scov/RVS/integration_resources/reference/integration_annexes/Cpus/rvs-ig-cpus-powerpc.pdf"
category: "src/scov/RVS/integration_resources/reference/integration_annexes/Cpus"
pages: 10
extracted: "2026-07-06T23:14:24.322622"
---
# Rvs Ig Cpus Powerpc
> Extracted from `./src/scov/RVS/integration_resources/reference/integration_annexes/Cpus/rvs-ig-cpus-powerpc.pdf` (10 pages).
> Figures, diagrams, and tables may not render accurately in plain text.
PowerPC
Integration Annex
Version WF20190404
Disclaimer
The information, text, and graphics contained within this document are
provided for information purposes only by Rapita Systems Ltd. Rapita
Systems Ltd. does not warrant the accuracy or completeness of the
information, text, and other items contained in this document.
Copyright and Trademarks
All rights reserved. Information and images contained within this doc-
ument are copyright and the property of Rapita Systems Ltd. All trade-
marks are hereby acknowledged to be the properties of their respective
owners.
Acknowledgments
Rapita Systems' tools are built using AdaCore's GNAT Pro compiler.
Rapita Systems Ltd.
Registered in the UK, number 5011090.
Registered address:
Atlas House
Link Business Park
Osbaldwick Link Road
York
YO10 3JB
UK
Phone: +44 (0) 1904 413 945
http://www.rapitasystems.com/
This document copyright © 2019, Rapita Systems Ltd.
Document build 118520
ID: DOC/12012
1 PowerPC
1.1 Obtaining a timestamp
There are two methods of obtaining a timestamp on most PowerPC processors:
the time base registers and performance counters. The granularity of the time base
registers is system dependent and must be known in order to convert clock ticks
to real times. The cycle accurate performance counter is generally more accurate
and can be converted to real time by using the CPU frequency. However, it is not
available all processors and must be configured before use. This section explains
how to use both of these registers.
1.1.1 Reading the time base registers
The time base register set is two 32 bit registers containing the upper and lower
portions of a 64 bit value. It is sufficient and more efficient to simply read the lower
portion provided the time between instrumentation points does not allow the lower
part to wrap around more than once. A macro for reading the lower 32 bits is given
in Example 1.1. Note that the variable t should be declared as a 32 bit value.
Example 1.1: Reading 32 bit time base with GCC inline assembly syntax
#define GET_TIME_BASE(t) \
asm volatile( "mftb %0" : "=r"(t) )
If it is necessary to read both the upper and lower portions, a check must be
implemented to ensure that the high order register does not increment while the
lower register is being read. This is shown using an inline function and GCC inline
assembly syntax in Example 1.2.
Example 1.2: Reading 64 bit time base
static inline uint64_t get_time_base_64()
{
register uint32_t l, u1, u2;
do {
asm volatile( "mftbu %0\n\t"
"mftb %1\n\t"
"mftbu %2"
: "=r"(u1), "=r"(l), "=r"(u2) );
} while (u1 != u2);
return ((uint64_t)u1 << 32) + l;
}
RVS Integration Guide WF20190404 — PowerPC Integration Annex 3
Obtaining a timestamp PowerPC
1.1.2 Reading the time base register (e200 cores / MPC5xx)
On an e200 core, the time base lower 32 bits can be read in user mode from
special purpose register 268. The time base upper 32 bits can be read from special
purpose register 269.
Special purpose registers can be copied to a general purpose register using the
mfspr (move from special purpose register) instruction. An example of this is
provided in Example 1.3.
Example 1.3: Reading time base with GCC on e200 core
#define RVS_GET_TIME(t) \
asm volatile( "mfspr %0,268" : "=r"(t) )
1.1.3 Reading the performance monitor cycle counter (e300 /
e600 cores)
Before the performance counter can be read, it must be configured to count cy-
cles.
A PowerPC based on an e300 or e600 core has up to 6 performance counter reg-
isters (depending on model) called PMC1, PMC2 … PMCn. These can only be
accessed in supervisor mode. User mode registers UPMC1, UPMC2 … UPMCn
allow the values to read in user mode. The event which a register counts is config-
ured using monitor mode control registers named MMCR0, MMCR1 … MMCRn.
These must be written to in supervisor mode. This usually requires setting at sys-
tem startup within the OS.
Example 1.4 details the process of modifying MMCR0 to allow a cycle count to be
read from UPMC1 while the system is running.
MMCR0 is special purpose register number 952. Setting only bit 6 in this register
will cause PMC1 to count cycles. This is labeled bit 25 in PowerPC manuals where
31 is the least significant bit.
The example below gives assembly code to achieve this. An immediate value can-
not be written directly to a special purpose register so r0 is used as an interme-
diate register.
Example 1.4: Initializing PMC1 to count cycles
addi r0,0,64
mtspr 952,r0
Once the performance counter has been configured, it can be read from UPMC1
which is special purpose register 937. This is shown in Example 1.5
Example 1.5: Reading UPMC1 with GCC
#define GET_UPMC1(t) \
asm volatile( "mfspr %0,937" : "=r"(t) )
4 RVS Integration Guide WF20190404 — PowerPC Integration Annex
PowerPC Obtaining a timestamp
1.1.4 Reading the performance monitor cycle counter (e500
cores)
Before the performance counter can be read, it must be configured to count cy-
cles.
A PowerPC based on the e500 core uses specific instructions (mfpmr and mtpmr)
for reading from and writing to performance monitor registers.
The counters called PMC0, PMC1 … PMCn can be configured to count particular
events. These can only be accessed in supervisor mode. User mode registers
UPMC0, UPMC1 … UPMCn allow the values to read in user mode.
The events that are counted are configured using PMCGC0, the global perfor-
mance monitor control register and local control registers PMLCa0, PMLCa1 …
PMLCan and PMLCb0, PMLCb1 … PMLCbn. These must be written to in super-
visor mode. This usually requires setting at system startup within the OS.
Example 1.6 details setting PMGC0 and PMLCa0 such that a cycle count can be
read from UPMC0 while the system is running.
PMGC0 is performance monitor register number 400 (0x190) and PMLCa0 is num-
ber 144 (0x90). The most significant bit of PMGC0 is used to freeze the counters
while they are configured and then restart them. PMLCa0 is used to configure
PMC0 to count clock cycles by setting bit 16 (bit 47 in PowerPC manuals where
32 bit registers are labeled MSB 32 … 63 LSB) to 1.
The example below shows assembly code to configure the counter. An immediate
value cannot be written directly to a performance monitor registers so r0 is used
as an intermediate register.
Example 1.6: Initializing PMC0 to count cycles
li r0,0x8000
mtpmr 400,r0
lis r0,1
mtpmr 144,r0
lis r0,0
mtpmr 400,r0
Once the performance counter has been configured, it can be read from UPMC0
which is performance monitor register 0. This is shown in Example 1.7
Example 1.7: Reading UPMC0 with GCC
#define GET_UPMC0(t) \
asm volatile( "mfpmr %0,0" : "=r"(t) )
RVS Integration Guide WF20190404 — PowerPC Integration Annex 5
Using a memory buffer and thread safety PowerPC
1.2 Using a memory buffer and thread safety
If your trace library implementation is writing to an in-memory buffer, you can use
the code shown in Example 1.8. This combines a 12 bit ipoint identifier with a 20
bit timestamp into a single 32 bit value. To use this, you must provide the --nbits
12 option to adains or cins. You must also set the read.wrap parameter to 20
in your trace filter file.
Example 1.8: Writing to a memory buffer
...
static inline void RVS_I(unsigned int I)
{
register unsigned long t;
GET_UPMC1(t);
*rvs_buffer_ptr = (t << 12) | I;
rvs_buffer_ptr++;
}
...
When there is a possibility of a context switch within the ipoint routine there is the
risk of this occurring between he write to the buffer and the pointer increment.
The PowerPC has a facility to reserve a memory address and load its value using
the lwarx instruction. The stwcx. instruction can then be used to store a value
to this address and set a flag (bit cr2 in condition register) except if the value has
changed, the write will fail indicated by not setting the flag. In this latter case we can
retry the sequence. A thread-safe version of Example 1.8 is given in Example 1.9.
Example 1.9: Thread-safe implementation of tracing to a memory buffer
static inline void RVS_I(unsigned int I)
{
register unsigned long t;
register unsigned long * reserved_ptr;
asm volatile (
"1:\n\t"
"lwarx %0,0,%2\n\t" /* get buffer ptr and reserve */
"mfspr %1,937\n\t" /* get time */
"addi 0,%0,4\n\t" /* calc next ptr (4 bytes) */
"stwcx. 0,0,%2\n\t" /* try update buffer ptr */
"bne- 1b" /* retry if write failed */
: "=&r"(reserved_ptr),"=&r"(t)
: "r"(&rvs_buffer_ptr)
: "r0" );
*reserved_ptr = (t << 12) | I;
}
With optimizations turned on, writing to a memory buffer as shown in Example 1.8
should be compiled to 8 instructions. The thread-safe version in Example 1.9 can
be done in 10 instructions excluding retries.
6 RVS Integration Guide WF20190404 — PowerPC Integration Annex
Writing to an output port on MPC5xx microcon-
PowerPC
trollers
1.3 Writing to an output port on MPC5xx
microcontrollers
This section describes some options for writing to an output port on MPC5xx mi-
crocontrollers. Please contact Rapita Systems for advice on other PowerPC based
microcontrollers.
Using an output port requires there to be available output pins on the board con-
nected to a data capture device such as an RTBx or logic analyzer. Note that pins
are often multiplexed and some pins on a port may be unavailable if your applica-
tion hardware and/or software has them allocated to other functions.
The MPC5xx series microcontrollers, present a number of options for general pur-
pose IO pins depending on what functionality is enabled on the board. Here we
present 3 options:
1. Queued Analog to Digital Converter Module (QADCM)
2. Queued Serial Multi Channel Module (QSMCM)
3. Modular IO System (MIOS) Parallel Port IO Submodule (MPIOSM)
Note
In our experience, a better signal has been obtained from QADCM and
QSMCM.
1.3.1 Relevant Registers
Before output pins can be written to, they must be configured. In general, this re-
quires configuring them to be used as general purpose IO pins rather than anoth-
er specific function and then configuring the data direction to output rather than
input. It may be possible to obtain greater signal strength and faster rise and fall
times with other configurations.
Table 1.1 gives the relevant registers on an MPC5xx for output pin configuration
and data output.
Table 1.1 MPC 5xx registers
Register Description
UMCR UIMB Module Configuration Register. Used to configure the U-BUS to
IMB3 interface to run at full speed.
PDMCR Pad Module Configuration Register. Used to set normal rather than
slow slew rate.
PORTQA_A Port Data Register for port A on QADC module A.
PORTQB_A Port Data Register for port B on QADC module A.
DDRQA_A Port Data Direction Register for port A on QADC module A.
RVS Integration Guide WF20190404 — PowerPC Integration Annex 7
Writing to an output port on MPC5xx microcon-
PowerPC
trollers
Register Description
DDRQB_A Port Data Direction Register for port B on QADC module A.
PORTQA_B Port Data Register for port A on QADC module B.
PORTQB_B Port Data Register for port B on QADC module B.
DDRQA_B Port Data Direction Register for port A on QADC module B.
DDRQB_B Port Data Direction Register for port B on QADC module B.
MPIOSMDR MIOS Parallel Port IO Submodule Data Register. Used to write to MPIO
pins.
MPIOSMDDR MIOS Parallel Port IO Submodule Data Direction Register. Configure
MPIO pins for output.
PORTQS Queued Serial Multi Channel Module A (QSMCM A) Port Data Register.
Note the register bit to QGPIO pin mapping is not sequential.
PQSPAR PORTQS Pin Assignment Register. Configure QGPIO pins for general
purpose IO.
DDRQS PORTQS Data Direction Register. Configure QGPIO pins for output.
The registers in Table 1.1 are memory mapped registers which can be read and
written to using particular addresses. Example 1.10 gives a set of definitions that
can be copied into an integration's rvs_ipoint.h file. (#include this file in
rvs.c so they are available for the implementation of RVS_Init.)
Example 1.10: Setting up registers in rvs_ipoint.h
...
typedef unsigned long uint32_t;
typedef unsigned short uint16_t;
typedef unsigned char uint8_t;
#define BASE 0 /* Offset derived from IMMR:ISB */
#define UMCR (*(volatile uint32_t*)(BASE+0x307F80uL))
#define PDMCR (*(volatile uint32_t*)(BASE+0x2FC03CuL))
#define QAD_A (*(volatile uint32_t*)(BASE+0x304800uL))
#define QAD_B (*(volatile uint32_t*)(BASE+0x304C00uL))
#define PORTQA_A (*(volatile uint8_t *)(QAD_A+0x6uL))
#define PORTQB_A (*(volatile uint8_t *)(QAD_A+0x7uL))
#define DDRQA_A (*(volatile uint8_t *)(QAD_A+0x8uL))
#define DDRQB_A (*(volatile uint8_t *)(QAD_A+0x9uL))
#define PORTQA_B (*(volatile uint8_t *)(QAD_B+0x6uL))
#define PORTQB_B (*(volatile uint8_t *)(QAD_B+0x7uL))
#define DDRQA_B (*(volatile uint8_t *)(QAD_B+0x8uL))
#define DDRQB_B (*(volatile uint8_t *)(QAD_B+0x9uL))
#define MPIOSMDR (*(volatile uint16_t*)(BASE+0x306100uL))
#define MPIOSMDDR (*(volatile uint16_t*)(BASE+0x306102uL))
#define PORTQS (*(volatile uint16_t*)(BASE+0x305014uL))
#define PQSPAR (*(volatile uint8_t *)(BASE+0x305016uL))
#define DDRQS (*(volatile uint8_t *)(BASE+0x305017uL))
...
8 RVS Integration Guide WF20190404 — PowerPC Integration Annex
Writing to an output port on MPC5xx microcon-
PowerPC
trollers
1.3.2 QADCM
There are two QADC modules, each of which contain a pair of 8 bit ports. Ex-
ample 1.11 illustrates configuration of port A on QADC module A. Example 1.12
shows usage of the port.
Example 1.11: Setting up PORTQA_A. Code to be placed in rvs.c
...
void RVS_Init()
{
UMCR = 0; /* high bus frequency */
PDMCR = 0x80000000uL; /* normal slew rate for QAD */
PORTQA_A = 0; /* Initialize pins low */
DDRQA_A = 0xFF; /* Set as output */
}
...
Example 1.12: RVS_I for PORTQA_A to be placed in rvs_ipoint.h
...
#define RVS_I( I ) ((void)(PORTQA_A = (I)))
...
1.3.3 QSMCM
The QSMCM has 12 pins, 7 of which are available for general purpose IO. Exam-
ple 1.13 contains sample code for configuration of QGPIO pins. Example 1.14 il-
lustrates usage of the port. The mapping from PORTQS register to QGPIO is not
direct and must be corrected. This can be done in hardware by mapping the sig-
nals in the connection to the data collection device or in software. The example
below details how to do this in software, this example uses a macro, thereby elim-
inating additional overhead (note the value of I is an integer constant).
Example 1.13: Setting up QGPIO in rvs.c
...
void RVS_Init()
{
UMCR = 0; /* high bus frequency */
PDMCR = 0x80000000uL; /* normal slew rate for QGPIO */
PORTQS = 0; /* Initialize pins low */
PQSPAR = 0; /* Set all pins for GPIO */
DDRQS = 0x7f; /* Set 7 pins as output */
}
...
Example 1.14: RVS_I for QGPIO to be put in rvs_ipoint.h
...
#define MAKE_QGPIO_VAL(X) \
((((X) >> 4) & 0x07) | (((X) << 3) & 0x78))
#define RVS_I( I ) ((void)(PORTQS = MAKE_QGPIO_VAL(I)))
...
RVS Integration Guide WF20190404 — PowerPC Integration Annex 9
Obtaining the stack pointer PowerPC
1.3.4 MPIOSM
MPIOSM is a 16 bit port. Example 1.15 gives the code required to configure the
port.
Example 1.15: Setting up MPIO in rvs.c
...
void RVS_Init()
{
UMCR = 0;
PDMCR = 0x10000000uL; /* normal slew rate for MIOS */
MPIOSMDR = 0; /* Initialize pins low */
MPIOSMDDR = 0xFFFF; /* Set pins for output */
}
...
Example 1.16: RVS_I for MPIOSM to be put in rvs_ipoint.h
...
#define RVS_I( I ) ((void)(MPIOSMDR = (I)))
...
1.4 Obtaining the stack pointer
For RapiSafeStack integrations, the stack pointer can be read from register r1 on
a PowerPC. Code to achieve this is given in Example 1.17. The output operand
should be a register to avoid directly changing the stack behavior.
Example 1.17: Reading stack pointer on a PowerPC
#define GET_STACK_POINTER(s) \
asm volatile( "mr %0,1" : "=r"(s) )
10 RVS Integration Guide WF20190404 — PowerPC Integration Annex

338
docs-extracted/src/scov/RVS/integration_resources/reference/integration_annexes/Cpus/rvs-ig-cpus-st_arm_cortex.md Normal file
View file

@ -0,0 +1,338 @@
---
title: "Rvs Ig Cpus St Arm Cortex"
source: "./src/scov/RVS/integration_resources/reference/integration_annexes/Cpus/rvs-ig-cpus-st_arm_cortex.pdf"
category: "src/scov/RVS/integration_resources/reference/integration_annexes/Cpus"
pages: 8
extracted: "2026-07-06T23:14:24.345513"
---
# Rvs Ig Cpus St Arm Cortex
> Extracted from `./src/scov/RVS/integration_resources/reference/integration_annexes/Cpus/rvs-ig-cpus-st_arm_cortex.pdf` (8 pages).
> Figures, diagrams, and tables may not render accurately in plain text.
ST ARM Cortex
Integration Annex
Version WF20190404
Disclaimer
The information, text, and graphics contained within this document are
provided for information purposes only by Rapita Systems Ltd. Rapita
Systems Ltd. does not warrant the accuracy or completeness of the
information, text, and other items contained in this document.
Copyright and Trademarks
All rights reserved. Information and images contained within this doc-
ument are copyright and the property of Rapita Systems Ltd. All trade-
marks are hereby acknowledged to be the properties of their respective
owners.
Acknowledgments
Rapita Systems' tools are built using AdaCore's GNAT Pro compiler.
Rapita Systems Ltd.
Registered in the UK, number 5011090.
Registered address:
Atlas House
Link Business Park
Osbaldwick Link Road
York
YO10 3JB
UK
Phone: +44 (0) 1904 413 945
http://www.rapitasystems.com/
This document copyright © 2019, Rapita Systems Ltd.
Document build 118520
ID: DOC/12062
1 ST ARM Cortex
This integration annex contains information to aid with integration to all versions
of the ARM Cortex architecture implemented by ST. For information on integration
with other ARM architectures or Cortex implementations from other manufacturers,
please contact the Rapita Systems support team at support@rapitasystems.com
for the appropriate annex.
Note that this guide refers to the Cortex architecture implementation by ST Mi-
crosystems (STM32xxxxxx) and libraries supplied by ST. Code examples will not
be valid for implementations by other SoC manufacturers
1.1 Obtaining a timestamp
All microprocessors in the STM family from ST include timer peripherals with 16 bit
timers. If the target device has 32 bit timers we recommend that one is used where
the integration requires an ipoint timestamp. Below is an example detailing the
process of enabling a 32 bit timer using the peripheral libraries that are supplied
by ST.
The sample RVS_Init function in Example 1.1 sets up the selected timer (TIM2)
to be a free-running up counter running at the main clock frequency. The specific
stm32fxxx_tim.h and stm32fxxx_rcc.h header files for the target must
be included in order to provide access to the timer and resource configuration
APIs.
Example 1.1: Setup and enable timer
...
void RVS_Init (void)
{
TIM_TimeBaseInitTypeDef SetupTimer;
/* Enable timer 2, using the Reset and Clock Control register */
RCC_APB1PeriphClockCmd(RCC_APB1Periph_TIM2, ENABLE);
SetupTimer.TIM_Prescaler = 0x0000;
SetupTimer.TIM_CounterMode = TIM_CounterMode_Up;
SetupTimer.TIM_Period = 0xFFFFFFFF;
SetupTimer.TIM_ClockDivision = TIM_CKD_DIV1;
TIM_TimeBaseInit(TIM2, &SetupTimer);
TIM_Cmd(TIM2, ENABLE); /* start counting by enabling CEN in CR1 */
}
...
The example sets up the clock to count up (CounterMode) to 32 bit
max (TIM_Period) at the main clock frequency (ClockDivision and
RVS Integration Guide WF20190404 — ST ARM Cortex Integration Annex 3
Using two 16 bit timers ST ARM Cortex
Prescaler). The timer is then enabled. This method provides a suitable time-
stamp for integrations requiring an ipoint timestamp.
Example 1.2: Sample ipoint implementation
...
RVS_I(unsigned int id)
{
/* get the timer value. */
unsigned long count = TIM_GetCounter(TIM2);
if (rvs_buffer_index < STORAGE_SIZE)
{
rvs_IPointStorage[rvs_buffer_index].ipointID = id;
rvs_IPointStorage[rvs_buffer_index].timestamp = count;
rvs_buffer_index++;
}
}
...
1.2 Using two 16 bit timers
Where there are no 32 bit timers available, it is possible to cascade two 16 bit
timers to achieve 32 bit accuracy. Some devices can be configured to cascade 16
bit timers in hardware, check your device's User Manual to confirm this is possible.
The sample code provided in Example 1.3 enables TIM3 for use as the master
(lower 16 bits) and TIM9 as the slave (upper 16 bits):
Example 1.3: Cascading two 16 bit timers to give 32 bit resolution
...
/* enable the timer peripherals: */
RCC->APB1ENR |= RCC_APB1Periph_TIM3;
RCC->APB2ENR |= RCC_APB2Periph_TIM9;
/* Master - TIM3 counts the lower 16 bits */
/* TIM3 should use the clock as it's input by default.*/
TIM3->PSC = 0x0000; /* no prescaler. */
/* set clock division to zero: */
TIM3->CR1 &= (uint16_t)(~TIM_CR1_CKD);
TIM3->CR1 |= TIM_CKD_DIV1;
TIM3->CR2 |= 0x20; /* MMS (6:4) */
/* slave - TIM9 counter the upper 16 bits */
TIM9->PSC = 0x0000;
/* set clock division to zero: */
TIM9->CR1 &= (uint16_t)(~TIM_CR1_CKD);
TIM9->CR1 |= TIM_CKD_DIV1;
TIM9->SMCR |= (TIM_TS_ITR1 | TIM_SlaveMode_External1);
/* enable the two counters: */
TIM9->CR1 |= TIM_CR1_CEN;
TIM3->CR1 |= TIM_CR1_CEN;
...
4 RVS Integration Guide WF20190404 — ST ARM Cortex Integration Annex
ST ARM Cortex Driving output pins for ipoints
Both timers should have their prescaler and clock division set to zero, the master
timer (TIM3) should be configured in Master Mode (TIM3_CR2:MMS = 010,
the master is then used as the prescaler for the slave).
The timer capturing the high 16 bits (TIM9 in this case ) must be configured as
follows:
The Trigger Selection must be set to TIM3 (001) so that the output from TIM3
acts as the input to TIM9
TIM9_SMCR:TS = 001
The Slave Mode Selection must be set to External Clock Mode 1
(111) this causes rising edges of the selected trigger (TRGI) to increment the
counter.
TIM9_SMCR:SMS = 111
Using two timers in this manner means that the ipoint implementation must
change.
Example 1.4: Ipoint for linked timers
...
RVS_I(unsigned int id)
{
unsigned long count = ((TIM9->CNT << 16) & TIM3->CNT);
if (rvs_index < STORAGE_SIZE)
{
rvs_IPoints[rvs_index].ipointID = id;
rvs_IPoints[rvs_index].timestamp = count;
rvs_index++;
}
}
...
1.3 Driving output pins for ipoints
Below is an example RVS_init implementation for configuring output pins. It
configures the first 8 pins of port B for output (PB0 .. PB7)
RVS Integration Guide WF20190404 — ST ARM Cortex Integration Annex 5
Thread-safe implementation ST ARM Cortex
Example 1.5: Initialize output pins for port B
...
void RVS_Init()
{
RCC_AHB1PeriphClockCmd(RCC_AHB1Periph_GPIOB, ENABLE);
GPIO_InitTypeDef GPIO_InitStructure;
GPIO_InitStructure.GPIO_Pin = GPIO_Pin_0 |
GPIO_Pin_1 |
GPIO_Pin_2 |
GPIO_Pin_3 |
GPIO_Pin_4 |
GPIO_Pin_5 |
GPIO_Pin_6 |
GPIO_Pin_7;
GPIO_InitStructure.GPIO_Mode = GPIO_Mode_OUT;
GPIO_InitStructure.GPIO_OType = GPIO_OType_PP;
GPIO_InitStructure.GPIO_PuPd = GPIO_PuPd_DOWN;
GPIO_InitStructure.GPIO_Speed = GPIO_Speed_100MHz;
GPIO_Init(GPIOB,&GPIO_InitStructure);
}
...
Below is an ipoint example which assumes that trace data is being collected via
the RTBx and the host board is running at 168MHz. As the RTBx has a maximum
sampling rate of 100MHz this means that the potential data rate output is above
the RTBx sampling rate - hence two nop instructions are added to decrease the
output rate and increase ipoint trace reliability.
Example 1.6: Inserting a delay for ipoints
static inline void rvs_delay(void)
{
asm volatile("mov r0,r0\n\t"
"mov r0,r0\n\t");
}
#define RVS_Ipoint(_I) (RVS_GPIOB->ODR=((_I)), rvs_delay())
#define RVS_I(_I) RVS_Ipoint(_I)
#define RVS_E(_I,_E) (RVS_I(_I),_E)
#define RVS_C(_I,_C) (RVS_E(_I,0)?_C:_C)
1.4 Thread-safe implementation
On systems using multiple threads, or multiple interrupts which are to be instru-
mented then the ipoint implementation must be safe from interruption.
The simplest way of doing this is simply to disable interrupts at the start of the
ipoint function and re-enable them at the end. This will ensure trace consistency
but could cause high overhead.
This can also be done using ARM specific instructions as shown in Example 1.7.
6 RVS Integration Guide WF20190404 — ST ARM Cortex Integration Annex
ST ARM Cortex Thread-safe implementation
Example 1.7: ARM specific thread-safe (Keil compiler) ipoint
void RVS_Ipoint(unsigned int id)
{
/* get the timer value. */
unsigned int count = TIM_GetCounter(TIM2);
int rvs_buffer_index, retval;
do
{
rvs_buffer_index = __ldrex(&ipoint_index);
if (rvs_buffer_index < STORAGE_SIZE)
{
rvs_IpointStorage[rvs_buffer_index].ipointID = id;
rvs_IpointStorage[rvs_buffer_index].timestamp = count;
rvs_buffer_index++;
}
/* returns zero if store is successful */
retval = __strex(rvs_buffer_index, &ipoint_index);
}
while(retval)
}
Note
This example is specific to the Keil compiler as the intrinsic functions
(__ldrex and __strex) are non-standard.
If your compiler does not have intrinsic functions for these ARM instructions then
inline assembler can be used. Example 1.8 shows an example using GCC inline
assembler syntax.
RVS Integration Guide WF20190404 — ST ARM Cortex Integration Annex 7
Thread-safe implementation ST ARM Cortex
Example 1.8: ARM specific assembler for thread-safe locking
void RVS_Ipoint(unsigned int id)
{
/* get the timer value. */
unsigned int count = TIM_GetCounter(TIM2);
int rvs_buffer_index, retval;
do
{
__asm("LDREX %[result], [%[address]]" :
[result] "=r" (rvs_buffer_index) :
[address] "r" (&ipoint_index));
if (rvs_buffer_index < STORAGE_SIZE)
{
IpointStorage[rvs_buffer_index].ipointID = id;
IpointStorage[rvs_buffer_index].timestamp = count;
rvs_buffer_index++;
}
/* returns zero if if store is successful */
__asm("STREX %[result], %[value], [%[address]]" :
[result] "=r" (retval) :
[value] "r" (rvs_buffer_index),
[address] "r" (&ipoint_index));
while(retval)
}
8 RVS Integration Guide WF20190404 — ST ARM Cortex Integration Annex

280
docs-extracted/src/scov/RVS/integration_resources/reference/integration_annexes/Data Collection/rvs-ig-collection-trace32.md Normal file
View file

@ -0,0 +1,280 @@
---
title: "Rvs Ig Collection Trace32"
source: "./src/scov/RVS/integration_resources/reference/integration_annexes/Data Collection/rvs-ig-collection-trace32.pdf"
category: "src/scov/RVS/integration_resources/reference/integration_annexes/Data Collection"
pages: 8
extracted: "2026-07-06T23:14:24.372678"
---
# Rvs Ig Collection Trace32
> Extracted from `./src/scov/RVS/integration_resources/reference/integration_annexes/Data Collection/rvs-ig-collection-trace32.pdf` (8 pages).
> Figures, diagrams, and tables may not render accurately in plain text.
Lauterbach TRACE32
Integration Annex
Version WF20190404
Disclaimer
The information, text, and graphics contained within this document are
provided for information purposes only by Rapita Systems Ltd. Rapita
Systems Ltd. does not warrant the accuracy or completeness of the
information, text, and other items contained in this document.
Copyright and Trademarks
All rights reserved. Information and images contained within this doc-
ument are copyright and the property of Rapita Systems Ltd. All trade-
marks are hereby acknowledged to be the properties of their respective
owners.
Acknowledgments
Rapita Systems' tools are built using AdaCore's GNAT Pro compiler.
Rapita Systems Ltd.
Registered in the UK, number 5011090.
Registered address:
Atlas House
Link Business Park
Osbaldwick Link Road
York
YO10 3JB
UK
Phone: +44 (0) 1904 413 945
http://www.rapitasystems.com/
This document copyright © 2019, Rapita Systems Ltd.
Document build 118520
ID: DOC/12014
1 Lauterbach TRACE32
1.1 Downloading data in memory to a file
If an in-memory buffer contains either a RapiTime timing trace or RapiCover map
data, the simplest way to process it is to download it as a binary data dump and
then use the read.byte_reader option to process it.
The command DATA.SAVE.BINARY should be used to download an area of
memory to a file. An address range can be specified either with absolute values
or using high level language symbols. The first argument to the command is a file
name and the second is the address range. The file name should be given the
extension .bin so that it can be read immediately using traceutils.
Example 1.1 and Example 1.2 give examples for using DATA.SAVE.BINARY.
Example 1.1: Extracting data using fixed address range
; range of fixed addresses, range is inclusive
DATA.SAVE.BINARY data.bin (0xA0000000--0xA0FFFFFF)
; using fixed base address and offset to final address
; for range (a++x), x+1 bytes are downloaded
DATA.SAVE.BINARY data.bin (0xA0000000++0x00FFFFFF)
Example 1.2: Extracting data using high level language symbols
; Using high level language symbols to specify range
; TRACE32 defaults to using address of a symbol
; VAR.VALUE function gets value of a pointer
; Here an example where start_ptr points to start of
; buffer and current_ptr is immediately after last
; value written
DATA.SAVE.BINARY data.bin (VAR.VALUE(start_ptr)--
(VAR.VALUE(current_ptr)-1))
; Command used to download a RapiCover map
DATA.SAVE.BINARY data.bin (VAR.VALUE(rvs_map_data)+
+(VAR.VALUE(rvs_map_data_size)-1))
; If buffer is statically allocated buffer can use
; Y.SIZEOF function to get its size
DATA.SAVE.BINARY data.bin ((buffer)++(Y.SIZEOF(buffer)-1))
; or Y.RANGE command to generate range for buffer
DATA.SAVE.BINARY data.bin (Y.RANGE(buffer))
RVS Integration Guide WF20190404 — Lauterbach TRACE32 Integration Annex 3
Using a Nexus Bus Trace Lauterbach TRACE32
1.1.1 Converting binary data to RVS data format
The data which has been downloaded can be read using a filter containing a
read.byte_reader filter option. Example 1.3 and Example 1.4 show filters for
two possible encodings of an ipoint ID and timestamp stored in a memory buffer.
Note the use of the read.wrap option which will handle wrap around of the time-
stamp data for a particular number of bits.
Example 1.3: Filter for binary data with 16 bit ipoint ID followed by 32 bit
timestamp
#16 bit ipoint ID, 32 bit timestamp
read.byte_reader( "B0 B1", "B2 B3 B4 B5");
read.wrap(32);
Example 1.4: Filter for binary data with 20 bit timestamp followed by 12 bit ipoint
ID
#20 bit timestamp combined with 12 bit ipoint ID
read.byte_reader("B2[4:7] B3", "B0 B1 B2[0:3]");
read.wrap(20);
Once the filter is written and stored in a filter file (e.g. reader.flt), the data
can be loaded using the steps shown in Example 1.5. The granularity of the timer
should be specified using the --clock-hz option. Note that this will be lower
than the CPU speed unless a cycle accurate timer is being used.
Example 1.5: Loading binary trace data into a report
traceutils reader.flt -o trace.rpz data.bin
timeparser --clock-hz 200_000_000 trace.rpz report.rvd
To process coverage map data, a filter containing a byte reader is provided along-
side the documentation. This should be combined with the memdump filter gen-
erated by rvdutils when the coverage map was created. Example 1.6 shows com-
mands to load a binary coverage map into a report.
Example 1.6: Loading binary map data into a report
traceutils "<RVS_ROOT>\integration_resources\template_rvslib\map\C
\byte_read.flt" -f rvs_map.memdump.flt -o map.rpz data.bin
covparser --map map.rpz report.rvd
1.2 Using a Nexus Bus Trace
If your target board has support for Nexus Class 3 or above then you can monitor
a memory address as a method of obtaining a trace.
4 RVS Integration Guide WF20190404 — Lauterbach TRACE32 Integration Annex
Lauterbach TRACE32 Using a Nexus Bus Trace
A variable should be declared within the rvs library which will be monitored by
the bus trace. Example 1.7 gives a suitable declaration which can be placed in
rvs.c. The variable is declared volatile to prevent the compiler removing
or reordering assignments to this variable. When choosing the data type for the
variable, the efficiency of assigning an immediate value to the variable on the target
platform should be considered.
Example 1.7: Declaring a variable to monitor in rvs.c
...
volatile unsigned int rvs_monitor;
...
Example 1.8 gives a suitable definition for RVS_I which will write the ipoint ID to
this variable.
Example 1.8: Implementing RVS_I in rvs_ipoint.h
...
extern volatile unsigned int rvs_monitor;
#define RVS_I(I) ((void)(rvs_monitor = (I)))
...
Example 1.9 gives a sequence of TRACE32 commands to configure the trace to
capture writes to the variable rvs_monitor. The necessary commands may
vary depending on how your system is configured. Other forms of tracing need to
be switched off or otherwise filtered during post processing.
Example 1.9: TRACE32 commands to configure the bus trace
;turn off other forms of tracing
NEXUS.BTM OFF
NEXUS.OTM OFF
;trace writes to rvs_monitor
BREAK.SET rvs_monitor /WRITE /TRACEDATA
;reset the trace buffer
TRACE.RESET
After capture, the trace can be written out in a text format using the commands
given in Example 1.10. This command will output the data stored (ipoint ID) and
a timestamp.
Example 1.10: TRACE32 commands to output captured trace to a file
printer.file data.txt
winprint.trace.list ((0-a.records())--0) data %tf ti.z
Example 1.11 shows a filter for reading the text file. The first characters of each
line contain an item number which should be skipped. The number of columns to
skip may vary with the length of trace.
RVS Integration Guide WF20190404 — Lauterbach TRACE32 Integration Annex 5
Initializing Registers or Memory Lauterbach TRACE32
Example 1.11: Filter for reading data trace file (trace32.flt)
#skip trace item number
skip_columns( "12" );
#read data as ipoint ID in hex and then
#timestamp as absolute value with units
line_reader( "IH TT" );
#scale down timer from picosecond to nanosecond
scale( 1, 1_000 );
This filter file can be used to process the data with the commands in Example 1.12.
The clock rate is specified at 1GHz based on the assumption timestamps are given
in nanoseconds after passing through the filter in Example 1.11.
Example 1.12: Loading binary trace data into a report
traceutils trace32.flt -o trace.rpz data.txt
timeparser --clock-hz 1_000_000_000 trace.rpz report.rvd
1.3 Initializing Registers or Memory
When some initialization needs to be performed and a debugger is available, per-
forming this initialization in a debugger startup script is often more convenient than
modifying and recompiling the operating system or board support package.
DATA.SET can be used to initialize a memory address to a particular value.
REGISTER.SET is used for standard CPU registers and PER.SET is for initial-
izing board specific peripheral registers. Example 1.13 shows how this could be
used to initialize special purpose register 952 on a PowerPC. The format specifiers
indicate that this is a long big endian register.
Example 1.13: Using TRACE32 to initialize performance counters on a PowerPC
e300
PER.SET SPR:952 %LONG %BE 64
1.4 Multiprocessor SMP Systems
If using a multiprocessor system, then it will be necessary to run commands on a
particular core. Some commands have a /CORE option to specify this. In general,
this can be done by using the CORE.SELECT command to select a core before
running other commands.
On some systems, TRACE32 can have difficulty using high level language symbol
names if the same symbol name is used multiple times in different memory areas.
In this situation a fall-back is to map symbols to known addresses and then use
those addresses within scripts. It is possible to test that TRACE32 disambiguates
6 RVS Integration Guide WF20190404 — Lauterbach TRACE32 Integration Annex
Lauterbach TRACE32 Multiprocessor SMP Systems
symbol names correctly by selecting a core and then trying to view the data with
VAR.VIEW.
RVS Integration Guide WF20190404 — Lauterbach TRACE32 Integration Annex 7
This page intentionally left blank

538
docs-extracted/src/scov/RVS/integration_resources/reference/integration_annexes/Data Collection/rvs-ig-collection-vx1000.md Normal file
View file

@ -0,0 +1,538 @@
---
title: "Rvs Ig Collection Vx1000"
source: "./src/scov/RVS/integration_resources/reference/integration_annexes/Data Collection/rvs-ig-collection-vx1000.pdf"
category: "src/scov/RVS/integration_resources/reference/integration_annexes/Data Collection"
pages: 14
extracted: "2026-07-06T23:14:24.400006"
---
# Rvs Ig Collection Vx1000
> Extracted from `./src/scov/RVS/integration_resources/reference/integration_annexes/Data Collection/rvs-ig-collection-vx1000.pdf` (14 pages).
> Figures, diagrams, and tables may not render accurately in plain text.
Vector VX1000
Integration Annex
Version WF20190404
Disclaimer
The information, text, and graphics contained within this document are
provided for information purposes only by Rapita Systems Ltd. Rapita
Systems Ltd. does not warrant the accuracy or completeness of the
information, text, and other items contained in this document.
Copyright and Trademarks
All rights reserved. Information and images contained within this doc-
ument are copyright and the property of Rapita Systems Ltd. All trade-
marks are hereby acknowledged to be the properties of their respective
owners.
Acknowledgments
Rapita Systems' tools are built using AdaCore's GNAT Pro compiler.
Rapita Systems Ltd.
Registered in the UK, number 5011090.
Registered address:
Atlas House
Link Business Park
Osbaldwick Link Road
York
YO10 3JB
UK
Phone: +44 (0) 1904 413 945
http://www.rapitasystems.com/
This document copyright © 2019, Rapita Systems Ltd.
Document build 118520
ID: DOC/13056
1 Vector VX1000
1.1 Using RVS with the Vector VX1000 system
The Vector VX1000 measurement and calibration interface is a high-speed debug-
ging interface for automotive ECUs. Connecting directly to the on-chip debug fa-
cilities provided by many commonly-used microcontrollers (such as the Infineon
TriCore series), it provide a mechanism for high bitrate data extraction with minimal
impact on the ECU execution.
The VX1000 system can be used to collect trace data for use with the RVS tools.
This annex describes the steps necessary to configure both the target device and
the analysis host to allow the collection and processing of ipoint data.
1.2 Target configuration
Data extraction with the VX1000 follows the XCP DAQ (data acquisition) method,
whereby a predefined set of data is collected by the analysis host on receipt of
a trigger event.
ipoint data is initially collected using an in-memory buffer on the target system,
which is then transferred as a single block of data by raising a VX1000 event when
the buffer becomes full.
1.2.1 In-memory buffer configuration
For ease of extraction, the data type of the buffer should be an array of unsigned
integers, and the ipoint and timestamp values should be assigned by bit-shifting
operations. Using a struct or union to hold the two values separately will com-
plicate the data transfer and processing stages, as CANape will refer to the two
elements separately.
We recommend using a double-buffering strategy due to the fact that data transfer
using the OLDA method requires the use of background time to complete the
transfer of data to the host system. Using a double buffer allows the collection of
ipoint data to continue uninterrupted using the second buffer while the background
task completes the transfer of the first. We recommend an initial size of 32 ipoints
for each buffer, although this may need to be increased depending on the exact
characteristics of the system being analyzed.
It is necessary to use a separate variable to maintain the index into the buffer. Ad-
ditionally, we recommend using the first buffer element as a sequence ID. This can
be verified during the data processing stage to ensure that there are no skipped
buffers in the collected trace.
RVS Integration Guide WF20190404 — Vector VX1000 Integration Annex 3
Target configuration Vector VX1000
Example 1.1 shows the code necessary to declare the ipoint buffers, index and
sequence ID.
Example 1.1: Configuring ipoint buffers for use with VX1000
/* Locate trace buffer in shared RAM section */
#pragma section all "RVS_TB"
#define RVS_STORAGE_SIZE 32
/* ipoint buffers */
uint32 IpointStorage1[RVS_STORAGE_SIZE];
uint32 IpointStorage2[RVS_STORAGE_SIZE];
/* Ipoint_index = index into buffer array */
uint32 IpointIndex = 1;
/* Ipoint_sequence_id = buffer sequence counter */
uint32 IpointSequenceID = 0;
#pragma section all
Important
If your target supports memory protection, you must ensure that the loca-
tion in RAM where the ipoint buffers, index and sequence ID variables are
placed is writable.
If you have instrumented functions that can be called from locations both
inside and outside the analysis root, you will need to make sure that all the
possible call locations can write to the ipoint buffer to avoid memory protec-
tion errors.
Consult your CPU and compiler documentation for further information about
memory protection and details of how to ensure that the ipoint buffers are
located in shared areas.
1.2.2 Ipoint implementation
As the transfer of data happens periodically, it is necessary to collect and store
a timestamp in the buffer for each recorded ipoint. Depending on the system be-
ing analyzed the number of bits required for ID and timestamp will vary, but as a
starting point we recommend using a 32-bit value for each ipoint, comprising 12
bits for the ipoint ID and 20 bits for the timestamp.
The VX1000 system provides the macro VX1000_CLOCK which can be used
to obtain a high-precision timestamp from the system. The source of the time-
stamp will vary depending on the target microcontroller. On TriCore devices, the
VX1000_CLOCK reads from the system timer STM_TIM0.
Example 1.2 shows the code necessary to encode the ipoint ID and timestamp
into a single 32-bit value and write it into the in-memory buffer.
4 RVS Integration Guide WF20190404 — Vector VX1000 Integration Annex
Vector VX1000 Target configuration
Example 1.2: Ipoint implementation - writing a value
void RVS_Ipoint(t_uint32 id)
{
uint32 IpointData;
IpointData = VX1000_CLOCK() & 0x000fffff;
IpointData |= (id << 20);
if (IpointIndex < RVS_STORAGE_SIZE)
{
/* Write to first buffer */
IpointStorage1[IpointIndex] = IpointData;
}
else
{
/* Write to second buffer */
IpointStorage2[(IpointIndex - RVS_STORAGE_SIZE)] =
IpointData;
}
/* Increment the buffer index */
IpointIndex++;
/* Code to trigger data transfer when buffer *
* is full goes here. */
}
1.2.3 Triggering VX1000 events
When a buffer is full, the ipoint function (RVS_Ipoint()) must trigger the trans-
fer of data to the host by raising a VX1000 DAQ event. Where multiple buffers
are used, a different event must be raised for each buffer. Appropriate event IDs
must be selected that are not already in use for other measurement or calibration
purposes.
The VX1000 event function must be made available to the ipoint routine by includ-
ing the appropriate VX1000 headers (for example, vx1000_tricore.h for Tri-
Core systems) in the rvs.c source file.
Important
The VX1000_EVENT function, and anything in its call tree, must not itself be
instrumented to avoid a circular dependency at compile-time.
Where the ctree function of xstutils is used to automatically generate instru-
mentation annotations for the call tree of an analysis root, we recommend
using an ignore_subprogram annotation for the VX1000_EVENT func-
tion to prevent it from being instrumented.
Example 1.3 demonstrates how an ipoint routine can be created to raise a VX1000
event when one of its two buffers are full.
RVS Integration Guide WF20190404 — Vector VX1000 Integration Annex 5
Host configuration Vector VX1000
Example 1.3: Example ipoint routine section for use with VX1000
/* Include VX1000 headers */
#include "vx1000_tricore.h"
#define RVS_VX_EVENT_IPOINT1 29
#define RVS_VX_EVENT_IPOINT2 30
...
if (IpointIndex == RVS_STORAGE_SIZE)
{
/* IpointStorage1 buffer is full */
/* Assign sequence ID to next buffer */
IpointStorage2[0] = IpointSequenceID++;
/* Raise VX event */
VX1000_EVENT(RVS_VX_EVENT_IPOINT1);
/* Increment index to allow IpointStorage2[0] *
* to be used for sequence ID. */
IpointIndex++;
}
if (IpointIndex == (RVS_STORAGE_SIZE * 2))
{
/* IpointStorage2 buffer is full */
/* Assign sequence ID to next buffer */
IpointStorage1[0] = IpointSequenceID++;
/* Raise VX event */
VX1000_EVENT(RVS_VX_EVENT_IPOINT2);
/* Reset index to allow IpointStorage1[0] *
* to be used for sequence ID. */
IpointIndex = 1;
}
Important
If your target supports memory protection, you must ensure that the call to
VX1000_EVENT is not subject to memory protection from any potential call
location.
If you have instrumented functions that can be called from locations both
inside and outside the analysis root, you will need to make sure that all the
possible call locations are permitted to raise VX1000 events.
Consult your CPU and compiler documentation for further information about
memory protection and details of how to ensure that the ipoint buffers are
located in shared areas.
1.3 Host configuration
Data collected from the VX1000 device must be captured and recorded by the
analysis host machine. Software capable of communicating with the VX1000 using
6 RVS Integration Guide WF20190404 — Vector VX1000 Integration Annex
Vector VX1000 Host configuration
the XCP over Ethernet protocol is required. In this annex we provide instructions
for the Vector CANape tool, however other tools supporting XCP over Ethernet can
be used instead.
We assume in this section that the basic VX1000 and ECU configuration has al-
ready been carried out and that the connection between CANape and the ECU
has been established.
Note
The examples in this section assume a target based on an Infineon TriCore
microcontroller. The exact settings may be different if you are using a target
based on another microcontroller family. Refer to the VX1000 and CANape
documentation or contact Rapita Systems support for further information.
1.3.1 Configuring the VX1000 events
Details of the VX1000 events that are raised when the ipoint buffers are full must
be added to the VX1000 event list in the CANape device configuration. The device
configuration dialog can be accessed by choosing Device Configuration from
the Device menu.
Each of the events required should be added separately. Ensure that the event
is configured as a DAQ event, and that the event channel number matches the
event ID raised by the ipoint routine. The event rate should be configured as
Not cyclic. Figure 1.1 shows the settings that should be entered to add a new
VX1000 event. Figure 1.2 shows a sample VX1000 event list after two ipoint events
have been added.
Note
CANape represents event IDs in hexadecimal, whereas the event ID in the
source code may use a different number system.
Figure 1.1: Adding an event to the VX1000 event list
RVS Integration Guide WF20190404 — Vector VX1000 Integration Annex 7
Host configuration Vector VX1000
Figure 1.2: VX1000 device configuration - event list
1.3.2 TriCore ED configuration
The VX1000 system can be used in conjunction with a TriCore ED microcontroller to
allow more detailed debugging of a TriCore-based system. In particular, the trace
window feature can be used to allow data to be transferred from the target memory
to the analysis host at a higher rate than can be achieved with the standard TriCore
part without requiring background CPU cycles.
By locating the RVS ipoint storage buffers inside these trace windows, it is possible
to increase the rate at which instrumentation can be collected (and therefore the
number of functions that can be instrumented simultaneously).
The size and location of the trace windows must be specified in the CANape de-
vice configuration. It is necessary to know the memory address or addresses cor-
responding to the ipoint storage buffers, and the size of each buffer. This informa-
tion can be used to specify the location and size of the trace window, as shown
in Figure 1.3.
Important
The size of the trace window must be large enough to allow it to cover the
whole of the ipoint buffer(s). It may be necessary to define multiple trace
windows if the buffer locations are not aligned.
8 RVS Integration Guide WF20190404 — Vector VX1000 Integration Annex
Vector VX1000 Host configuration
Note
The memory addresses corresponding to the ipoint storage buffers can be
found in the map file that is produced by the linker, if the buffer location is
not predefined.
Figure 1.3: VX1000 TriCore configuration
1.3.3 Recorder configuration
As the RVS tools are unable to directly read the ASAM MDF file format directly, it is
necessary to configure CANape to export the collected data in ASCII text format.
Additionally, for situations where it is necessary to collect timing measurements
alongside other measurement data, it is recommended that the timing measure-
ment data be saved to a separate trace file.
CANape uses the concept of recorders to save measurement data. A CANape
configuration can measure multiple signals, and send the measurement data to
one or more recorders. To add a recorder that can be used to output RVS data,
follow these steps:
• From the CANape main window, choose Measurement Configuration from
the Measurement menu, or press F4. In the left-hand pane of the measure-
ment configuration window, click on Recorder List.
RVS Integration Guide WF20190404 — Vector VX1000 Integration Annex 9
Host configuration Vector VX1000
• Right-click anywhere in the list of recorders and choose Insert in the con-
text menu, or press the Insert key. A new recorder will be added and its
properties pane will automatically be opened. In the recorder properties pane,
choose a name for the recorder and define the format for the output file name.
• Expand the options for the new recorder by clicking on the + next to the new
recorder name in the left-hand pane, then open the Options pane. Untick any
options that are selected by default. In the Behavior at measurement stop
section, choose the option to Convert measurement file(s) with and select
ASCII Export Converter in the drop-down box.
• Close the measurement configuration window. The recorder settings will be
saved automatically.
1.3.4 Importing the measurement signals
To collect ipoint data, the ipoint buffers must be defined as measurement signals
in CANape. There are two stages to this process: firstly, the measurement signals
must be defined in CANape's A2L database; once this is done the signals must be
added to the measurement object list and configured to output data to a recorder.
Defining the measurement signals
Follow these steps to define the measurement signals in the CANape's A2L data-
base:
• Ensure that the CANape map file is correctly specified in the device configura-
tion. Update the A2L database by choosing Update from the Database menu.
• Open the database editor (either choose Editor from the Database menu, use
the toolbar button, or press F6).
• In the left-hand pane, expand the MAP file to display the symbols. Locate the
ipoint storage arrays in the symbol list. Right-click on the array and choose
New variables from MAP structure. In the window that appears (Figure 1.4)
choose to insert the symbols into an existing group, and insert them as mea-
surement values. If your A2L database already contains measurement groups,
select a group to add the signals to. If your A2L database does not contain
any groups, you can either choose to create a new group to contain the ipoint
signals, or insert the signals into the top level of the database by choosing
Insert in group.
In the left-hand pane, expand the MAP file to display the symbols. Locate the
ipoint storage arrays in the symbol list. Right-click on the array and choose
New variables from MAP structure. In the window that appears (Figure 1.4)
choose to insert the symbols into an existing group, and insert them as mea-
surement values. If your A2L database already contains measurement groups,
select a group to add the signals to. If your A2L database does not contain
any groups, you can either choose to create a new group to contain the ipoint
signals, or insert the signals into the top level of the database by choosing
Insert in group.
10 RVS Integration Guide WF20190404 — Vector VX1000 Integration Annex
Vector VX1000 Host configuration
Repeat this step until all the necessary measurement buffer signals have been
added, then save the database and exit the database editor screen.
Figure 1.4: VX1000 - signal configuration
Warning
By default, CANape is set to only expand the first 16 elements in an array. If
the buffers in use on the target contain more than 16 elements, this must be
increased in order for CANape to be able to correctly measure the complete
buffer.
In the database editor window, choose Editor Settings from the Tools
menu, then click on Linker Map Reader. Set the Maximum Field value to a
number equal to (or greater than) the size of the largest buffer in use.
To apply this change, it is necessary to restart CANape. Once CANape has
ben restarted, update the database again and re-open the database editor.
Configuring the measurement objects
Once the measurement signals have been defined, follow these steps to configure
the signals to be measured.
• From the CANape main window, choose Measurement Configuration from
the Measurement menu, or press F4.
• Right-click anywhere in the measurement list and choose Insert signal in the
context menu, or press the Insert key. The Database Selection window ap-
pears.
RVS Integration Guide WF20190404 — Vector VX1000 Integration Annex 11
Host configuration Vector VX1000
• Select the objects corresponding to the buffer measurement signals, then
press the Apply button. Exit the database selection window when all the sig-
nals have been added.
• In the Measurement Configuration window, assign the appropriate event as
the measurement mode for each signal. The measurement mode should cor-
respond to the VX1000 event raised when the buffer is full. Ensure that the
ipoint signals are sent to an appropriate recorder that has been configured to
convert measurement data into ASCII format.
1.3.5 Collecting measurements
Once CANape is configured save the configuration, then follow this process to
collect measurement data from the target:
• Ensure the VX1000 is connected to the target system correctly, and that both
are powered on. Launch CANape and open the configuration that is set up
for ipoint data collection.
• Connect to the VX1000. This will initialize the connection to the target system.
CANape will report that it is online.
• Start the measurement by choosing Start from the Measurement menu, by
pressing F9, or by clicking on the "lighting bolt" button on the toolbar.
• When sufficient data has been collected, stop the measurement by choosing
Stop from the Measurement menu, by pressing ESC, or by clicking on the
red circle "stop" button on the toolbar. A dialog box will appear indicating that
the recorded data is being converted into ASCII format.
By default, the recorded measurement data will be located in the CANape
project directory, unless a different output location is specified. The ASCII text
file can be moved or copied to a more convenient location for processing.
1.3.6 Processing measurement data
Once the measurement data has been collected, the ASCII text file generated by
CANape must be converted to produce a trace file that is compatible with the RVS
tools.
Rapita Systems Ltd. can provide a conversion tool (CANape_converter.exe) that
can read the text output produced by CANape and output an RVS trace file in text
format. This tool should be installed in <RVSROOT>/bin so that it is located on
the system path from within the RVS environment.
The CANape_converter tool is called from the command line. It takes a single
parameter, which is the CANape-format ASCII file to be converted. The RVS-format
output is automatically saved into a text file named corrected_trace.txt in
the current working directory.
The tool will automatically interpret values contained in fields with names starting
IpointStorage. It supports the use of single or double-buffering strategies
12 RVS Integration Guide WF20190404 — Vector VX1000 Integration Annex
Vector VX1000 Host configuration
and will automatically detect whichever is in use. The tool assumes the following
properties about the encoded trace data:
• That each buffer element contains an integer value corresponding to an en-
coded ipoint ID and timestamp, where the 12 most-significant bits indicate
the ipoint ID and the 20 least-significant bits are the timestamp. Different bit
assignments can be supported on request.
• That the first element of each buffer contains an encoded buffer sequence
ID that occupies at least the least-significant 16 bits. This is used by the tool
to check that the recorded data is complete. If any buffers are found to be
missing from the trace data, the tool will abort processing at the point the
missing buffer is detected and will exit with an error.
• The 16 most-significant bits of the first element of the first buffer are read prior
to the start of the processing and interpreted as a build ID in the range 0-65535.
This will be included at the beginning of the output trace file, and can then be
checked against a build ID encoded in the RVD file(s). If the build ID is not
required, it can be removed from the output trace with traceutils.
The resulting corrected_trace.txt file can then be processed further using
the traceutils tool. It will be necessary to correct timer wraparounds using the
-w 20 option, or by using a read.wrap(20); filter.
RVS Integration Guide WF20190404 — Vector VX1000 Integration Annex 13
This page intentionally left blank

479
docs-extracted/src/scov/RVS/integration_resources/reference/integration_annexes/Data Collection/rvs-ig-collection-xcp.md Normal file
View file

@ -0,0 +1,479 @@
---
title: "Rvs Ig Collection Xcp"
source: "./src/scov/RVS/integration_resources/reference/integration_annexes/Data Collection/rvs-ig-collection-xcp.pdf"
category: "src/scov/RVS/integration_resources/reference/integration_annexes/Data Collection"
pages: 12
extracted: "2026-07-06T23:14:24.422008"
---
# Rvs Ig Collection Xcp
> Extracted from `./src/scov/RVS/integration_resources/reference/integration_annexes/Data Collection/rvs-ig-collection-xcp.pdf` (12 pages).
> Figures, diagrams, and tables may not render accurately in plain text.
Universal Measurement
and Calibration Protocol
(XCP) Integration Annex
Version WF20190404
Disclaimer
The information, text, and graphics contained within this document are
provided for information purposes only by Rapita Systems Ltd. Rapita
Systems Ltd. does not warrant the accuracy or completeness of the
information, text, and other items contained in this document.
Copyright and Trademarks
All rights reserved. Information and images contained within this doc-
ument are copyright and the property of Rapita Systems Ltd. All trade-
marks are hereby acknowledged to be the properties of their respective
owners.
Acknowledgments
Rapita Systems' tools are built using AdaCore's GNAT Pro compiler.
Rapita Systems Ltd.
Registered in the UK, number 5011090.
Registered address:
Atlas House
Link Business Park
Osbaldwick Link Road
York
YO10 3JB
UK
Phone: +44 (0) 1904 413 945
http://www.rapitasystems.com/
This document copyright © 2019, Rapita Systems Ltd.
Document build 118520
ID: DOC/13057
Universal Measurement and
1 Calibration Protocol (XCP)
1.1 Using RVS with the Universal Measurement and
Calibration Protocol (XCP)
The Universal Measurement and Calibration Protocol (XCP) is a network protocol
to allow adjustment of internal parameters and acquisition of the current values of
internal variables of an ECU at runtime. XCP provides a common protocol interface
which is supported over a variety of physical interfaces, including CAN, FlexRay
and Ethernet.
XCP can be used to collect trace data for use with the RVS tools, subject to the
availability of sufficient bandwidth being available. It is recommended that RVS
data collection using XCP be carried out using high-bandwidth networks (such as
FlexRay or Ethernet) where possible.
This annex describes the steps necessary to configure both the target device and
the analysis host to allow the collection and processing of ipoint data for use with
the RVS tools.
1.2 Target configuration
To collect data via XCP, the target system must include an appropriate XCP dri-
ver. For most automotive ECUs, XCP support will already be incorporated into the
system to allow measurement and calibration information to be transferred during
development and testing.
Data extraction with the XCP uses the XCP DAQ (data acquisition) method, where-
by a predefined set of data is collected by the analysis host on receipt of a trigger
event. Depending on the XCP implementation, it may be necessary to define the
available XCP events in the target application code.
ipoint data is initially collected using an in-memory buffer on the target system,
which is then transferred as a single block of data by raising an XCP event when
the buffer becomes full.
1.2.1 In-memory buffer configuration
For ease of extraction, the data type of the buffer should be an array of unsigned
integers, and the ipoint and timestamp values should be assigned by bit-shifting
operations. Using a struct or union to hold the two values separately will com-
plicate the data transfer and processing stages, as CANape will refer to the two
elements separately.
RVS Integration Guide WF20190404 — XCP 3
Universal Measurement and Calibration Protocol
Target configuration
(XCP)
We recommend using a double-buffering strategy due to the fact that data transfer
using the XCP DAQ method requires the use of background time to complete the
transfer of data to the host system. Using a double buffer allows the collection of
ipoint data to continue uninterrupted using the second buffer while the background
task completes the transfer of the first. We recommend an initial size of 32 ipoints
for each buffer, although this may need to be increased depending on the exact
characteristics of the system being analyzed.
It is necessary to use a separate variable to maintain the index into the buffer. Ad-
ditionally, we recommend using the first buffer element as a sequence ID. This can
be verified during the data processing stage to ensure that there are no skipped
buffers in the collected trace.
Example 1.1 shows the code necessary to declare the ipoint buffers, index and
sequence ID.
Example 1.1: Configuring ipoint buffers for use with XCP
/* Locate trace buffer in shared RAM section */
#pragma section all "RVS_TB"
#define RVS_STORAGE_SIZE 32
/* ipoint buffers */
uint32 IpointStorage1[RVS_STORAGE_SIZE];
uint32 IpointStorage2[RVS_STORAGE_SIZE];
/* Ipoint_index = index into buffer array */
uint32 IpointIndex = 1;
/* Ipoint_sequence_id = buffer sequence counter */
uint32 IpointSequenceID = 0;
#pragma section all
Important
If your target supports memory protection, you must ensure that the loca-
tion in RAM where the ipoint buffers, index and sequence ID variables are
placed is writable.
If you have instrumented functions that can be called from locations both
inside and outside the analysis root, you will need to make sure that all the
possible call locations can write to the ipoint buffer to avoid memory protec-
tion errors.
Consult your CPU and compiler documentation for further information about
memory protection and details of how to ensure that the ipoint buffers are
located in shared areas.
4 RVS Integration Guide WF20190404 — XCP
Universal Measurement and Calibration Protocol
Target configuration
(XCP)
1.2.2 Ipoint implementation
As the transfer of data happens periodically, it is necessary to collect and store
a timestamp in the buffer for each recorded ipoint. Depending on the system be-
ing analyzed the number of bits required for ID and timestamp will vary, but as a
starting point we recommend using a 32-bit value for each ipoint, comprising 12
bits for the ipoint ID and 20 bits for the timestamp.
The timestamp must be acquired from a high-precision timer - exactly how this
is acquired will depend on the target microcontroller. For example, on TriCore de-
vices, the system timer STM_TIM0 can be used. For more details, see the appro-
priate integration annex for your microcontroller.
Example 1.2 shows the code necessary to encode the ipoint ID and timestamp
into a single 32-bit value and write it into the in-memory buffer.
Example 1.2: Ipoint implementation - writing a value
void RVS_Ipoint(uint32 id)
{
uint32 IpointData;
/* Create data point */
IpointData = STM_TIM0.U & 0x000fffff;
IpointData |= (id << 20);
if (IpointIndex < RVS_STORAGE_SIZE)
{
/* Write to first buffer */
IpointStorage1[IpointIndex] = IpointData;
}
else
{
/* Write to second buffer */
IpointStorage2[(IpointIndex - RVS_STORAGE_SIZE)] =
IpointData;
}
/* Increment the buffer index */
IpointIndex++;
/* Code to trigger data transfer when buffer *
* is full goes here. */
}
1.2.3 Triggering XCP events
When a buffer is full, the ipoint function (RVS_Ipoint()) must trigger the transfer
of data to the host by raising an XCP DAQ event. Where multiple buffers are used,
a different event must be raised for each buffer. Appropriate event IDs must be
selected that are not already in use for other measurement or calibration purposes.
Depending on the XCP implementation, it will be necessary to define these events
either in the application source code or by means of a code generation tool sup-
plied by the XCP driver vendor. If possible, the events should be defined without
RVS Integration Guide WF20190404 — XCP 5
Universal Measurement and Calibration Protocol
Target configuration
(XCP)
a cyclic period. If the XCP implementation requires a period to be set, this should
be set to the smallest value.
The XcpEvent function must be made available to the ipoint routine by including
the appropriate XCP headers (for example, XcpProf.h) in the rvs.c source file.
Important
The XcpEvent function, and anything in its call tree, must not itself be in-
strumented to avoid a circular dependency at compile-time.
Where the ctree function of xstutils is used to automatically generate instru-
mentation annotations for the call tree of an analysis root, we recommend
using an ignore_subprogram annotation for the XcpEvent function to
prevent it from being instrumented.
Example 1.3 demonstrates how an ipoint routine can be created to raise an XCP
event when one of its two buffers are full.
Example 1.3: Example ipoint routine section for use with XCP
/* Include XCP headers */
#include "XcpProf.h"
#define RVS_XCP_EVENT_Ipoint1 10
#define RVS_XCP_EVENT_Ipoint2 11
...
if (IpointIndex == RVS_STORAGE_SIZE)
{
/* IpointStorage1 buffer is full */
/* Assign sequence ID to next buffer */
IpointStorage2[0] = IpointSequenceID++;
/* Raise XCP event */
XcpEvent(RVS_XCP_EVENT_Ipoint1);
/* Increment index to allow IpointStorage2[0] *
* to be used for sequence ID. */
IpointIndex++;
}
if (IpointIndex == (RVS_STORAGE_SIZE * 2))
{
/* IpointStorage2 buffer is full */
/* Assign sequence ID to next buffer */
IpointStorage1[0] = IpointSequenceID++;
/* Raise XCP event */
XcpEvent(RVS_XCP_EVENT_Ipoint2);
/* Reset index to allow IpointStorage1[0] *
* to be used for sequence ID. */
IpointIndex = 1;
}
6 RVS Integration Guide WF20190404 — XCP
Universal Measurement and Calibration Protocol
Host configuration
(XCP)
Important
If your target supports memory protection, you must ensure that the call to
XcpEvent is not subject to memory protection from any potential call loca-
tion.
If you have instrumented functions that can be called from locations both
inside and outside the analysis root, you will need to make sure that all the
possible call locations are permitted to raise XCP events.
Consult your CPU and compiler documentation for further information about
memory protection and details of how to ensure that the ipoint buffers are
located in shared areas.
1.3 Host configuration
Data collected over XCP must be captured and recorded by the analysis host
machine. Software capable of communicating with the ECU over XCP is required.
In this annex we provide instructions for the Vector CANape tool, however other
tools supporting XCP can be used instead.
We assume in this section that the basic network and ECU configuration has al-
ready been carried out and that the connection between CANape and the ECU has
been established. Details of the XCP events that are raised when the ipoint buffers
are full will be automatically transferred from the ECU and added to CANape's XCP
event list when a connection to the device is established.
1.3.1 Recorder configuration
As the RVS tools are unable to directly read the ASAM MDF file format directly, it is
necessary to configure CANape to export the collected data in ASCII text format.
Additionally, for situations where it is necessary to collect timing measurements
alongside other measurement data, it is recommended that the timing measure-
ment data be saved to a separate trace file.
CANape uses the concept of recorders to save measurement data. A CANape
configuration can measure multiple signals, and send the measurement data to
one or more recorders. To add a recorder that can be used to output RVS data,
follow these steps:
• From the CANape main window, choose Measurement Configuration from
the Measurement menu, or press F4. In the left-hand pane of the measure-
ment configuration window, click on Recorder List.
• Right-click anywhere in the list of recorders and choose Insert in the con-
text menu, or press the Insert key. A new recorder will be added and its
properties pane will automatically be opened. In the recorder properties pane,
choose a name for the recorder and define the format for the output file name.
• Expand the options for the new recorder by clicking on the + next to the new
recorder name in the left-hand pane, then open the Options pane. Untick any
RVS Integration Guide WF20190404 — XCP 7
Universal Measurement and Calibration Protocol
Host configuration
(XCP)
options that are selected by default. In the Behavior at measurement stop
section, choose the option to Convert measurement file(s) with and select
ASCII Export Converter in the drop-down box.
• Close the measurement configuration window. The recorder settings will be
saved automatically.
1.3.2 Importing the measurement signals
To collect ipoint data, the ipoint buffers must be defined as measurement signals
in CANape. There are two stages to this process: firstly, the measurement signals
must be defined in CANape's A2L database; once this is done the signals must be
added to the measurement object list and configured to output data to a recorder.
Defining the measurement signals
Follow these steps to define the measurement signals in the CANape's A2L data-
base:
• Ensure that the CANape map file is correctly specified in the device configura-
tion. Update the A2L database by choosing Update from the Database menu.
• Open the database editor (either choose Editor from the Database menu, use
the toolbar button, or press F6).
• In the left-hand pane, expand the MAP file to display the symbols. Locate the
ipoint storage arrays in the symbol list. Right-click on the array and choose
New variables from MAP structure. In the window that appears (Figure 1.1)
choose to insert the symbols into an existing group, and insert them as mea-
surement values. If your A2L database already contains measurement groups,
select a group to add the signals to. If your A2L database does not contain
any groups, you can either choose to create a new group to contain the ipoint
signals, or insert the signals into the top level of the database by choosing
Insert in group.
Repeat this step until all the necessary measurement buffer signals have been
added, then save the database and exit the database editor screen.
8 RVS Integration Guide WF20190404 — XCP
Universal Measurement and Calibration Protocol
Host configuration
(XCP)
Figure 1.1: XCP - signal configuration
Warning
By default, CANape is set to only expand the first 16 elements in an array. If
the buffers in use on the target contain more than 16 elements, this must be
increased in order for CANape to be able to correctly measure the complete
buffer.
In the database editor window, choose Editor Settings from the Tools
menu, then click on Linker Map Reader. Set the Maximum Field value to a
number equal to (or greater than) the size of the largest buffer in use.
To apply this change, it is necessary to restart CANape. Once CANape has
ben restarted, update the database again and re-open the database editor.
Configuring the measurement objects
Once the measurement signals have been defined, follow these steps to configure
the signals to be measured.
• From the CANape main window, choose Measurement Configuration from
the Measurement menu, or press F4.
• Right-click anywhere in the measurement list and choose Insert signal in the
context menu, or press the Insert key. The Database Selection window ap-
pears.
• Select the objects corresponding to the buffer measurement signals, then
press the Apply button. Exit the database selection window when all the sig-
nals have been added.
• In the Measurement Configuration window, assign the appropriate event as
the measurement mode for each signal. The measurement mode should cor-
RVS Integration Guide WF20190404 — XCP 9
Universal Measurement and Calibration Protocol
Host configuration
(XCP)
respond to the XCP event raised when the buffer is full. Ensure that the ipoint
signals are sent to an appropriate recorder that has been configured to con-
vert measurement data into ASCII format.
1.3.3 Collecting measurements
Once CANape is configured save the configuration, then follow this process to
collect measurement data from the target:
• Ensure the target system is connected correctly to the host machine, and that
it is powered on. Launch CANape and open the configuration that is set up
for ipoint data collection.
• Connect to the device. This will initialize the connection to the target system.
CANape will report that it is online.
• Start the measurement by choosing Start from the Measurement menu, by
pressing F9, or by clicking on the "lighting bolt" button on the toolbar.
• When sufficient data has been collected, stop the measurement by choosing
Stop from the Measurement menu, by pressing ESC, or by clicking on the
red circle "stop" button on the toolbar. A dialog box will appear indicating that
the recorded data is being converted into ASCII format.
By default, the recorded measurement data will be located in the CANape
project directory, unless a different output location is specified. The ASCII text
file can be moved or copied to a more convenient location for processing.
1.3.4 Processing measurement data
Once the measurement data has been collected, the ASCII text file generated by
CANape must be converted to produce a trace file that is compatible with the RVS
tools.
Rapita Systems Ltd. can provide a conversion tool (CANape_converter.exe) that
can read the text output produced by CANape and output an RVS trace file in text
format. This tool should be installed in <RVSROOT>/bin so that it is located on
the system path from within the RVS environment.
The CANape_converter tool is called from the command line. It takes a single
parameter, which is the CANape-format ASCII file to be converted. The RVS-format
output is automatically saved into a text file named corrected_trace.txt in
the current working directory.
The tool will automatically interpret values contained in fields with names starting
IpointStorage. It supports the use of single or double-buffering strategies
and will automatically detect whichever is in use. The tool assumes the following
properties about the encoded trace data:
• That each buffer element contains an integer value corresponding to an en-
coded ipoint ID and timestamp, where the 12 most-significant bits indicate
the ipoint ID and the 20 least-significant bits are the timestamp. Different bit
assignments can be supported on request.
10 RVS Integration Guide WF20190404 — XCP
Universal Measurement and Calibration Protocol
Host configuration
(XCP)
• That the first element of each buffer contains an encoded buffer sequence
ID that occupies at least the least-significant 16 bits. This is used by the tool
to check that the recorded data is complete. If any buffers are found to be
missing from the trace data, the tool will abort processing at the point the
missing buffer is detected and will exit with an error.
• The 16 most-significant bits of the first element of the first buffer are read prior
to the start of the processing and interpreted as a build ID in the range 0-65535.
This will be included at the beginning of the output trace file, and can then be
checked against a build ID encoded in the RVD file(s). If the build ID is not
required, it can be removed from the output trace with traceutils.
The resulting corrected_trace.txt file can then be processed further using
the traceutils tool. It will be necessary to correct timer wraparounds using the
-w 20 option, or by using a wrap(20); filter.
RVS Integration Guide WF20190404 — XCP 11
This page intentionally left blank