CCSv4: Accessing the LoggerBuf after an assert.

Eddie3909

Other Parts Discussed in Thread: SYSBIOS

CCSv4.2.4, BIOS 6.31.4.27, IPC 1.22.3.23, Processor C6472

Our DSP is connected via SRIO to a host CPU and upon an error asserts, we'd like the host CPU to read the loggerbuffer for post error analysis. The CPU can read the DSP's memories via SRIO, but we need to know what address the logger buffer is at.

I've read the CCS help xdc/runtime/LoggerBuf.xdc looking for an API that returns the logger buf heap address. No luck. Its likely part of the LoggerBuf_obj, but I can;t find that definition either.

We create are logger instance in the .cfg below.

var LoggerBuf = xdc.useModule('xdc.runtime.LoggerBuf');

Exc.common$.logger = LoggerBuf.create();

var instLoggerBuf0Params0 = new LoggerBuf.Params();

instLoggerBuf0Params0.numEntries = 768;

var instLoggerBuf0 = LoggerBuf.create(instLoggerBuf0Params0);

I can pass the logger handle instLoggerBuf0 to the main DSP code using Program.global.LOGGER_HANDLE = instLoggerBuf0. And then put the handle in a predefined memory location for the host CPU to read. Via SRIO, the host can access LoggerBuf_obj, but how can it get the loggerbuf address to upload the raw log data from the DSP?

With the handle, the CPU could use the LoggerBuf.c functions LoggerBuf_flush(), LoggerBuf_getNextEntry() and the log.c Log_doPrint(), but that would require us to give the logger LoggerBuf_obj and the Logger Buffer to the CPU. I'd prefer to keep it simple (and hence less resistence by them to implementing it), and ask the CPU guys to simply upload the raw loggerbuf and logger obj to process the data offline.

Other references

C:\Program Files\Texas Instruments\bios_6_31_04_27\docs\cdoc\index.html

http://e2e.ti.com/support/embedded/f/355/p/130967/503474.aspx#503474

http://processors.wiki.ti.com/index.php/Multicore_System_Analyzer

over 13 years ago

0 BrianC over 13 years ago

TI__Expert 3745 points

Hi,

The key data structures that you need to reference in order to programmatically upload the contents of the LoggerBuf buffer and instance state are all 'internal' and are not available for use in your application code. So you'll be forced to write code that may break in the future when the internal data structures used by LoggerBuf change. Are you ok with this type of short-term approach?

If not, are you ok with upgrading to CCSv5.1 and using the System Analyzer + UIA (unified instrumentation architecture) packages in order to use more flexible loggers?

Regards,

Brian

0 Eddie3909 over 13 years ago in reply to BrianC

Guru 10385 points

Hi Brian

BrianC said:
are you ok with upgrading to CCSv5.1 and using the System Analyzer + UIA

Does it mean I can keep all my current BIOS, CGT, XDS, and IPC? I can sell the migration to 5.1 easier if I tell the boss that its just the GUI?

Otherwise, I think I have to go with

BrianC said:
you'll be forced to write code that may break in the future when the internal data structures used by LoggerBuf change

Cheers

0 BrianC over 13 years ago in reply to Eddie3909

TI__Expert 3745 points

Hi Eddie,

UIA 1.00.01.17 supports the versions of BIOS, CGT and IPC you are using. Your current XDS emulation pods will work with this. I need to check where you can download the UIA 1.00.01.17 release from, since a later release of UIA is being installed with CCSv5.1.

CCSv5.1 provides a lot of enhancements vs. CCSv4.2 that should help to sell the migration: see http://processors.wiki.ti.com/images/4/4a/CCSv5-WhatsNew.pdf for a summary of how CCSv5.1 compares to CCSv4.

There are a number of new capabilities that UIA and System Analyzer enable that may also help to sell the migration to CCSv5.1:

multicore event correlation: allows you to see the timing relationship between events that are logged on different CPUs
real-time event monitoring: run-mode jtag allows you to monitor events in the lab, ethernet transport allows you to upload events via UDP in the lab or the field.
the roadmap is for RTA to be phased out and be replaced with System Analyzer + UIA. System Analyzer + UIA are part of TIs multicore tooling strategy

Please let me know how you want to proceed. Either way, I'll do my best to help you access the log data you need.

Regards,

Brian

0 Eddie3909 over 13 years ago in reply to BrianC

Guru 10385 points

Hi Brian

I'm downloading CCSv5 to give it a try. But in paralllel I'd like to download the logger obj and loggerbuff to the CPU to see how that goes. I suspect migrating to CCSv5 will take some time given the maturity of our development phase.

Now that I've reviewed the CCSv5 slides you sent, I'm confident we'll likely stay with CCSv4 until out next big release (in approx ~ 8 mo). So I'd definitely like to learn more about the CCSv4 option.

Cheers

0 BrianC over 13 years ago in reply to Eddie3909

TI__Expert 3745 points

OK, great.

To upload the logger buffer contents, please try the following:

#include <xdc/std.h>
#include <xdc/runtime/Log.h>
#include <xdc/runtime/LoggerBuf.h>

/* To get globals from .cfg Header */
#include <xdc/cfg/global.h>

extern const xdc_runtime_LoggerBuf_Handle hLogger;
extern far Ptr xdc_runtime_LoggerBuf_Instance_State_0_entryArr__A;

#define NUM_LOGGER_ENTRIES (100)
#define HACK_EVENTENTRY_SIZE (8*sizeof(UInt32))
#define HACK_LOGGERBUF_STATEINFO_SIZE (256)
#define HACK_EVENTARRAY_SIZE (HACK_EVENTENTRY_SIZE * NUM_LOGGER_ENTRIES)

UInt32 eventArray[HACK_EVENTARRAY_SIZE/4];
UInt32 stateInfoArray[HACK_LOGGERBUF_STATEINFO_SIZE/4];

Void uploadEventBuf(){
int i=0;
UInt32* pEventBuffer = (UInt32 *)&xdc_runtime_LoggerBuf_Instance_State_0_entryArr__A;
   UInt32* pLoggerState = (UInt32 *)hLogger;

   for (i=0;i< (HACK_EVENTARRAY_SIZE/4);i++){
      eventArray[i] = *pEventBuffer++;
   }

for (i=0;i< (HACK_LOGGERBUF_STATEINFO_SIZE/4);i++){
      stateInfoArray[i] = *pLoggerState++;
   }

}

with the following .cfg code:

var LoggerBuf = xdc.useModule('xdc.runtime.LoggerBuf');

var loggerParams = new LoggerBuf.Params();
loggerParams.numEntries = 100; // Must match NUM_LOGGER_ENTRIES #define in .c code
logger = LoggerBuf.create(loggerParams);
Program.global.hLogger = logger;

This should give you the basic idea of how to find the appropriate data structures and figure out how much to upload. Note that the HACK_LOGGERBUF_STATEINFO_SIZE is set to a much larger size than you should need. You can get by with 44 bytes.

To decode the buffer, load the same version of the program that you uploaded the data from into a CPU in your lab that has CCS connected to it, run it at least to main, then copy the memory that you uploaded into the memory of your CPU in the lab. Then use Tools->ROV to view the internal state of the LoggerBuf module.

(For info on ROV, please search the CCS online help for "RTSC Object Viewer".)

I hope this gets you started - please post if you have any questions.

Regards,

Brian

0 Eddie3909 over 13 years ago in reply to BrianC

Guru 10385 points

Hi Brian

BIOS 6.33.05.46, IPC 1.24.03.32, xdctools 3.23.02.47, CGT 7.2.6

I'm finally getting around to implementing your suggestion. I've observed that the array

xdc_runtime_LoggerBuf_Instance_State_0_entryArr__A

has no data in it. However I noticed there are 4 others that do.

xdc_runtime_LoggerBuf_Instance_State_1_entryArr__A

xdc_runtime_LoggerBuf_Instance_State_2_entryArr__A

xdc_runtime_LoggerBuf_Instance_State_3_entryArr__A

xdc_runtime_LoggerBuf_Instance_State_4_entryArr__A

How does one know which to upload? Do they somehow correlate to diags_USER1, diags_USER2, etc?

Update: I just realised that only State_0 has the same number of entries I've specified in the .cfg file. So obviously that must be the one that should have log info. Its strange that I can see the log info in the Printf Logs window, but nothing shows in the State_0 array.

And LoggerBuf0 (your hLogger above) is pointing to the beginning of the State_0 log buffer however it doesn't seem to be updating the curEntry pointer.

So next I looked at the tools->RTA->Raw logs and discovered that nothing is in my loggerBuf0 and only the "Main Logger" is getting logs.

Below is our .cfg logger setup

var LoggerBuf = xdc.useModule('xdc.runtime.LoggerBuf');
var loggerBuf0Params = new LoggerBuf.Params();
loggerBuf0Params.numEntries = 256;
loggerBuf0Params.instance.name = "loggerBuf0";
Program.global.loggerBuf0 = LoggerBuf.create(loggerBuf0Params);
Main.common$.logger = Program.global.loggerBuf0;

So the mapping must be something like

loggerBuf0 -> ....State_0.... (has 256 entries as expected)
RTASupportLog -> ....State_1....(has 1 entry)
RTASystemLog -> ....State_2....(has 128 entries)
RTALoadLog -> ....State_3.... (has 15 entries)
Main Logger -> ....State_4.... (has 31 entries)

Where is Main Logger specified and why would my logs be going to it instead of loggerBuf0?

Before I left for vacation, the logs used to go into loggerBuf0, but obviously something has changed. The .cfg is still the same, but we used to be on BIOS 6.31.4.27, ipc 1.22.3.23 and xdctool 3.20.8.88. Perhaps the new bios or xds changed the logger behavior?

New configuration

CGT 7.2.6.
IPC 1.24.3.23
SYS/BIOS 6.33.5.46
XDCtools 3.23.2.47

I've compared an old clearcase view with our current build using the same .cfg but with the latest tools (specified at the beginning of this thread) and when I click on Diags, the LoggerBuf tab with xdc.runtime shows nothing for Memory or Diagnostics. The "Problems" tab says "cannot read property cfgScript" from undefined". Rats, another problem with the latest tools. I'll specify this problem in another post.

How do I specify the size of the other logs? (i.e. RTALoadLog, RTASystemLog, etc.)

Also, which of the build files does CCS use to correlate the event tag to the log print formatting of the text string? (unless this is in the .out, we should also store this file(s) in clearcase for our build release)

Cheers
Eddie

0 BrianC over 13 years ago in reply to Eddie3909

TI__Expert 3745 points

Hi Eddie,

Sorry for the delayed response. I'm in the process of setting up a system with the components that you've specified to better understand what you are seeing. I'll post again once I have more info.

Regards,

Brian

0 BrianC over 13 years ago in reply to BrianC

TI__Expert 3745 points

Hi Eddie,

Re: Where is Main Logger specified and why would my logs be going to it instead of loggerBuf0?

Recent versions of SysBios have changed the way instrumentation is handled in order to simplify the steps needed to set things up. The ti.sysbios.rta.Agent module now handles creation and configuration of all instrumentation buffers. If you look closely at the build console output of your project, you should see something like the following warning:

Main.common$.logger has already been assigned, Agent reassigning logger to 'Main Logger'

In order to specify the size of the main logger, you will now need to replace the .cfg script you are using to create the loggerBuf0 buffer with the following:

var Main = xdc.useModule('xdc.runtime.Main');
var Agent = xdc.useModule('ti.sysbios.rta.Agent');
Agent.mainLoggerSize = 256 * LoggerBuf.Entry.$sizeof();

The HACK code needed to determine the location of the buffer to upload needs to be changed to the following:

#define NUM_LOGGER_ENTRIES (256)
#define HACK_EVENTENTRY_SIZE (8*sizeof(UInt32))
#define HACK_LOGGERBUF_STATEINFO_SIZE (256)
#define HACK_EVENTARRAY_SIZE (HACK_EVENTENTRY_SIZE * NUM_LOGGER_ENTRIES)
#define HACK_OFFSETOF_EVENT_ENTRY_ADRS (2*sizeof(UInt32))
UInt32 eventArray[HACK_EVENTARRAY_SIZE/4];
UInt32 stateInfoArray[HACK_LOGGERBUF_STATEINFO_SIZE/4];
...

Void uploadEventBuf(){
   int i=0;

   UInt32* pLoggerState = (UInt32 *)xdc_runtime_Main_Module__loggerObj__C;
   UInt32* pEventBuffer = (UInt32*)*(UInt32 *)((UInt32)pLoggerState + HACK_OFFSETOF_EVENT_ENTRY_ADRS);

   printf("Logger at 0x%x, buffer at 0x%x\n",pLoggerState,pEventBuffer);
   for (i=0;i< (HACK_EVENTARRAY_SIZE/4);i++){
      eventArray[i] = *pEventBuffer++;
   }

   for (i=0;i< (HACK_LOGGERBUF_STATEINFO_SIZE/4);i++){
      stateInfoArray[i] = *pLoggerState++;
   }

}

NOTE that this code is an unsupported hack that is likely to fail when you upgrade to later versions of xdc / SysBios. As previously mentioned, using UIA and System Analyzer instead is strongly recommended.

Re: How do I specify the size of the other logs? (i.e. RTALoadLog, RTASystemLog, etc.)

See the CDocs for ti.sysbios.rta.Agent. The key configuration parameters are:

Agent.sysbiosLoggerSize, Agent.loadLoggerSize and Agent.mainLoggerSize .

Re: Also, which of the build files does CCS use to correlate the event tag to the log print formatting of the text string? (unless this is in the .out, we should also store this file(s) in clearcase for our build release)

You will need both the .out file and the *.rta.xml file that is generated at build time in the <output dir>/configPkg/package/cfg folder (e.g. for the stairstep example program, this is in Debug/ConfigPkg/package/cfg/stairstep_p366.rta.xml).

I hope this helps.

Regards,

Brian

0 Eddie3909 over 13 years ago in reply to BrianC

Guru 10385 points

Thanks Brian

For all you other DSPrs, here is a related link

http://e2e.ti.com/support/embedded/bios/f/355/p/207331/736187.aspx

Processors

Processors forum

CCSv4: Accessing the LoggerBuf after an assert.