BIOS 6 Real-Time Analysis (RTA) in CCSv4

Overview

This article provides troubleshooting support for using the RTA tools in CCSv4 with a BIOS 6 (SYS/BIOS) application. For BIOS 5 (DSP/BIOS) applications, see BIOS 5 Real-Time Analysis (RTA) in CCSv4.

Using RTA

Getting Started

For information on getting started with BIOS 6 RTA, please see the following resources:

• The 'Instrumentation' chapter of the BIOS User Guide (available as a pdf in the 'docs' directory of the product, or accessible through Help in CCS).
• The BIOS 6 Stairstep example
• For a tutorial for configuring your application for RTA support, see this article.

Here are RTA views for BIOS6, available under Tools menu:

Stop Mode RTA

Users of RTA in CCSv3 are familiar with a feature of RTA where the views display data when the target is halted, even if no data is being received while the target is running. This feature is called "stop mode" RTA.

When the target is halted, the RTA tools directly read and clear the Log buffers on the target, and display any new Log records in the views. This can be very helpful for seeing the most recent Log events, as well as for retrieving records when there is a problem with RTDX.

Stop Mode Buttons

The RTA views include two buttons for controlling the behavior of stop-mode RTA.

The purpose of these buttons is to allow you to manage how and when RTA updates in stop-mode. If the target buffers are particularly large, you may find that stop-mode RTA can make the GUI sluggish if you are single-stepping through code, since it will read and decode the target buffers on every step. These buttons essentially give you the option of manually controlling when stop-mode happens.

If the 'Enable RTA continuous refresh' button is toggled on, then stop-mode RTA will automatically update every time the target is halted (by hitting halt, reaching a breakpoint, etc.). This button is enabled by default. When the target is running, this button cannot be toggled, and will appear greyed-out.

If you disable this first button, then the second button can be used to manually tell stop-mode RTA to refresh. It will only refresh once per target halt, regardless of how many times the button is pressed.

Multi-Core RTA

RTA currently has limited support for multi-core applications. Each core must run RTA separately, and the data is not correlated between the different cores and can only be viewed per-core.

When you open an RTA view on a multi-core device, the view will display the data received from the core which is currently selected in the CCS debug manager.

When you select a different core, you may find that the 'Stream RTA data' button in the RTA view is disabled. You will need to enable this to start receiving data from that core.

When loading an RTA-enabled application on more than four cores of a device, you will get an error about RTDX not having enough buffers configured. See the "Six-Core Devices" section under Troubleshooting for details.

Unknown State in Execution Graph

For various reasons, RTA is often unable to transmit the log data from the target to the host quickly enough to not lose any data. This causes there to be gaps in the data received by RTA, and this has important implications for the state of the Execution Graph in RTA.

When there is a gap in RTA data, you will see this marked in the Raw Logs view by a pseudo-record showing the break in sequence numbers of the records received, and the transition of the "currentThread" state to "Unknown".

Note the jump in 'seqId' from 15313 to 15381.

Whenever there is a gap in data, the execution graph must also forget whatever it knows about the current state of the system, since the state has likely changed during that gap. The execution graph will display a red line labeled "Unknown" until it receives another record indicating the state of the system.

After the gap in data, RTA does not know which Task is currently running in the system until it receives a Task switch event indicating that the scheduler is switching to a different Task. Often what you will see after a gap in data is that you receive some Hwi or Swi events, indicating that a Hwi or Swi has run for a particular period of time, and the execution graph will plot those. However, once that Hwi or Swi exits, RTA does not know which Task we return to, so it continues to display the state as "Unknown". It will continue to do this until it receives a Task switch event, at which point it knows which Task is running and can display that.

There is a gap between records 4878 and 4904, so the state becomes unknown. We receive Hwi and Swi events 4904 - 4907, which are plotted, but then we don't know which Task is running so 'currentThread' becomes "Unkown" again at 4907.

RTA Control Panel

“XDC Loggerbuffs” with their corresponding “modules” are shown in a table tree where modules are listed under the logger bufs they belong. XDC diagnostic flags for a given module are shown in columns. Note that only runtime feature of an XDC diagnostic flag might be changed here and if during the XDC configuration a flag is marked ALAWYS_ON or ALWAYS_OFF, it cannot be modified and the corresponding table cell is disabled. Certain system modules are reserved and disabled for any modification as well.

To make any changes, the program needs to be running.

To enable/disable logging for a LoggerBuf click on the LoggerBuf node:

To control Runtime characteristic of modules click on the corresponding diagnostics cell:

If the program is running, changes take affect immediately and get reflected on RTA data views otherwise, they take affect as soon as program resumes running.

The runtime values of modules or everything shown in table tree can be refreshed by clicking, Refresh, on toolbar or off the context menu of the row.

Duration for RTA Steaming

The timer button, off RTA Control panel tool bar or context menu, brings up a dialog where user can specify for how long the streaming has to be continued.

If a number is specified, data will be collected for as long and after timer reaches zero, RTA streaming button will be toggled off to stop the streaming.

Default value 0 means collect data forever.

RTA Update Rate

The alarm clock, off RTA Control panel tool bar or context menu, brings up a dialog where user can specify how often statistics or data needs to be updated.

RTA Disk Usage

The green disk button off RTA Control panel tool bar or tool bar menu of RTA views, brings up RTA preferences where user could change the disk usage quota for RTA.

RTA makes use of file buffers to store collected data from the target. To limit the amount of temporary file space consumed by RTA, you may set this value.

System checks the disk space usage every minute, and if RTA exceeded this quota, data collection will be stopped. The consumed disk space, will be released as soon as CCS is

You may also modify where these temporary files are saved, by changing "CCS/Advanced Tools/Temp Directory" preference

Troubleshooting

No data received

• Ensure that the "Stream RTA data" button is enabled (it should be by default). Toggling this button off will completely shutdown RTA (though the window will stay open), and toggling it back on will start a fresh RTA session. The below screenshot shows this button in its enabled state. This button is enabled by default, and it must be enabled for RTA to function.

• In between target 'restart's or reloads, make sure to perform a target reset (Alt + R).
• The target responds to requests for RTA data while it is in the idle loop. In order to receive any RTA data while the target is running, the application must spend at least some time idle.
• Try the BIOS 6 stairstep example first. If the stairstep example doesn't work, then RTDX may not be supported on your board or emulator.

RTDX fails intermittently

Unfortunately, there are known issues with RTDX on various combinations of targets and emulators. If RTDX stops working, you can try toggling the 'Stream RTA data' button (towards the top right of the view) off, then on again. This re-initializes RTA and may resolve the issue. If not, you will likely have to terminate and relaunch your debug session (just the debug session, not the entire CCS IDE) to resolve it.

RTA Menu Is Greyed-Out

If you attempt to open RTA through Tools -> RTA, and find that all of the RTA menu items are greyed-out, and see an exception in the error log:

Double click on the exception in the error log to view it in more detail.

If the exception begins with the following message:

com.ti.dvt.rta.interfaces.IRTAFactory$RTAFactoryException: java.lang.Exception: Cannot find the required file stairstep_p64P.rta.xml. The original path to the file does not exist: C:/Documents and Settings/My Documents/workspace/Stairstep_evm6472_BIOS6/Debug/configPkg/package/cfg/stairstep_p64P.rta.xml If the file is missing, please rebuild the associated RTSC configuration. Otherwise, if the path is no longer valid, please move the file to: C:\Documents and Settings\My Documents\workspace\Stairstep_evm6472_BIOS6\Debug\stairstep_p64P.rta.xml

Then RTA is missing a required file associated with your application configuration. Check the path listed in the exception to ensure it's valid; you may simply need to rebuild your application.

If you receive a different exception message, post it to the BIOS forums [[1]] to get help.

RTA on a different machine

Another possible cause for this error is if you build your application on one machine, then try to run it in CCS on a different machine. RTA requires the .rta.xml meta data file to run, and the executable contains an absolute path to the original location of this file. If you try to run RTA on your application on a different machine, this absolute path may no longer be valid.

There are two options to work around this.

1. There is a path mapping dialog which CCS leverages for locating source files. In XDCtools 3.20.05.76 and later, RTA will leverage this dialog for locating the required .rta.xml meta data file. You can find this dialog in CCS under Window -> Preferences, then under C/C++ -> Debug -> Common Source Lookup Path. This is helpful when the application is built and resides on a network, and the networked drive has different mappings on different machines. Note: There is currently a bug with this approach when mapping one Windows path to another. It seems to work when mapping Linux paths to Windows, however.
2. In all versions of XDCtools, if RTA fails to find the .rta.xml file in its original location, it will also try looking in the directory which contains the built executable. You can copy the .rta.xml file from its original location to sit next to the executable and RTA will find it (this is the approach suggested by the error message). If you do this, be sure to copy the .rta.xml file over every time you modify the configuration, or you may experience other errors in RTA.

Six-core devices ("Too Few RTDX Host Buffers")

If you try loading an RTA application on all cores in a six-core device such as the evm6472, you will get the following RTDX warning:

This is because RTDX is configured by default with only four buffers, and requires at least one buffer per core.

The following attached script can be used to configure RTDX to use six buffers.

Media:InitRtdx.zip

1. Unzip this file to C:/initRtdx.js
2. Launch your debug session and connect the target, but don't load your .out file yet.
3. Opening the 'Scripting Console' under Window -> Show View -> Scripting Console.
4. At the prompt, type the following and hit enter

<source lang="text">loadJSFile C:/initRtdx.js</source>

After this, you should be able to load and run all of the cores.

IMPORTANT: When switching between cores, ensure that the 'Stream RTA Data' toggle button is enabled in whatever RTA view you're looking at. It may be disabled when you first switch to another core.