logger module in xdc runtime package

Do you speak about examples around this?

The module "examples.runtime.Mod" should be specified within Mod.xdc, which should to be find within a subdirectory "examples/runtime/Mod.xdc" within one of the specified XDC package directories.

Regards,
Joern.

Sasha,

thanks for your support, but could you share with me some basic example which shows how to build our own packages. for me as a beginner its difficult to proceed.

Hi,

How can I see the logged buffer data in memory,because LoggerBuf_flush prints on the console as well as getNextEntry does not provide output in the readable format.

 I also want to use statusLogger in LogBuffer module, but i am not able to utilize it.

I don't understand what's wrong with the console output, but if you want to see the content of the buffer in memory, you can use ROV. When you open a debug session, and load a program, go to Tools->ROV. After you execute the program, click on LoggerBuf in the ROV tab. There, you can go to the Records tab and see every record. The column 'text' displays the content of a LoggerBuf entry.

As for 'statusLogger', what kind of a problem do you have? Have you created a separate logger instance and assign it to LoggerBuf.statusLogger? That separate LoggerBuf instance will contain only events for which the STATUS bit is set.

Hi Shasha,

Can I have two LoggerBuf instances and utilize them in the code simulataneously, if yes how to configure them in the application code?

for STATUSLogger i have written the following code :

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

var LoggerBufParams0 = new LoggerBuf.Params;

var logger0 = LoggerBuf.create(LoggerBufParams0); // logger instance is created

var LoggerBufParams1 = new LoggerBuf.Params;

var logger1 = LoggerBuf.create(LoggerBufParams1); // logger instance is created for the STATUS Logger

LoggerBuf.statusLogger = logger1;

Main.common$.diags_INFO = Diags.RUNTIME_ON;

Defaults.common$.logger = logger0;

Program.global.logger = logger0;

I dont know where to set STATUS bit.

Please Correct me, if some mistake has done by me.

Regards,

Abhishek

Abhishek,
you created two LoggerBuf instances in the config code in your last post. Normally, you would configure their usage in the config script. There is not much to configure in C code. You can use multiple loggers for different purposes. For example, iIf you wanted to log events from RTSC modules separately from events logged from your app, you could create two loggers, logger0 and logger1, similar to what you already did in your post. Then, you would specify that by default all modules use logger 0:
Defaults.common$.logger = logger0;
Then, you can use the module Main to specify a different logger, logger1, for your application code:
Main.common$.logger = logger1;
There could be other scenarios where you could use multiple loggers, this is just one of them.

The STATUS bit is a part of a diagnostics mask that each module has. You set it the same way you did for the INFO bit:
Main.common$.diags_STATUS = Diags.RUNTIME_ON;
or
Main.common$.diags_STATUS = Diags.ALWAYS_ON;

However, you shouldn't have to do any of these to see warnings and errors in statusLogger. The STATUS bit is ON by default. If you are not seeing any events in statusLogger, It's possible that your app does not generate any warnings or errors. You can try adding a Log_error call to your app, just to see if it goes to statusLogger:

Log_error0("Hello error!");

Sasha,

Status Logger I have seen in ROV , but can we use LoggerBuf_flush() to see them in console?

LoggerBuf.statusLogger = logger1;

Program.global.statusLogger = logger1;// to make it global

I included  #include <xdc/cfg/global.h> this file.

Apart from it, can we have two logger instances for the same module (say Main), if yes then how can both will be utilized? (means some log events are captured inside one logger instances and rest are in others). For implementing own package and module i have seen the Example5 provided in the Error Module, as much could I understand (module_name.c, module_name.xdc, module_name.xdc.h, module_name.xs, package_name.bld, package_name.cfg), these mentioned file we have to write it by own, rest are generated automatically. when other files are generated means when we use them in our application.cfg file??

Please specify what we have to mention in .xs and .xdc.h and .xdc files?

May be my doubts are so basics??, but as a beginner its difficult for me to proceed.

Warm Regards,

Abhishek

Abhishek Kumar said:

Sasha,

Status Logger I have seen in ROV , but can we use LoggerBuf_flush() to see them in console?

logger0.enableFlush = true;
logger1.enableFlush = true;

Then, in your C code, call the function that flushes all LoggerBufs:
LoggerBuf_flushAll();

Abhishek Kumar said:

Apart from it, can we have two logger instances for the same module (say Main), if yes then how can both will be utilized? (means some log events are captured inside one logger instances and rest are in others).

You can't have more than one logger for the same module. As I wrote in an earlier post, you can only separate warnings and errors for all modules into a different logger.
There are some solutions that could in effect allow you to log events to different loggers in your app, but they are little bit more complicated and could take more time to work them out. One possibility is to use LoggerBuf instances directly, without making Log calls. You could also create your own logger, as in this advanced example, and then you can intercept log messages, filter them or reroute them to other loggers. I am not going to go into details of these solutions because the first one is not recommended and we don't have any examples, while for the second one there is already the linked example from which you can start.

But, why do you want to have two different loggers? How are you going to use them?

Abhishek Kumar said:

For implementing own package and module i have seen the Example5 provided in the Error Module, as much could I understand (module_name.c, module_name.xdc, module_name.xdc.h, module_name.xs, package_name.bld, package_name.cfg), these mentioned file we have to write it by own, rest are generated automatically. when other files are generated means when we use them in our application.cfg file??

Please specify what we have to mention in .xs and .xdc.h and .xdc files?

The example you are referencing contains all the files you need to run it. You have to have package.bld and package.xdc. Then for each module you have to create <module_name>.xdc, <module_name>.xs and <module_name>.xs. If you are building an app in the same package, then you need <app_name>.cfg and <app_name>.c.

This example explains in more details what goes to each file. You may want to read through some other examples in the RTSC Module Primer, just to get a better idea which files are used for what.

8546.err_xdc.docx

Sasha,

I have encountered error why running the primer lesson1 as well as building the package, Ihave attached the file for your reference.
Changes made by me in the "common.mak" & "config.bld"  is highlighted as given in the "xdctool user guide". I don't know what wrong with that.

Abhishek,
the first error in the document you posted is caused by backslashes in your compiler path. The supplied path is treated as a string in XDCscript, and backslashes are recognized as escape characters. We recommend using forward slashes everywhere in XDCtools, and they work just fine on Windows. So, set your compiler path in config.bld to "C:/Program Files/CCS_4.2.3/ccsv4/tools/compiler/c6000", and try again. Same goes for the Gnu compiler path and all other paths in your Make files, change them all to use forward slashes.

The C6x compiler options you are asking about is documented in the compiler help:
--no_compress                Disable compression for 6400+

It means that the compiler will not compress instructions. That functionality is used when you need to oprimize code for space as oposed to speed. The option -O2 is a standard compiler option that sets a standard optimization level for the code ready to be released. These options are selected as a reasonable default, but you can change them or delete them if they don't suite your needs.

The last error you are getting is a bug in the ti.platforms.sim64Pxx package in XDCtools 3.20.08. You can update XDCtools or you fix it in your 3.20.08 installation by changing the file  "C:/Program Files/CCS_4.2.3/xdctools_3_20_08_88/packages/ti/platforms/sim64Pxx/Platform.xs".
The line
command = packagePath + os + "/kelvin -quiet -mem_ignore " + java.io.File(prog.name).getAbsolutePath();
in function getExecCmd() should be replaced with
command = "'" + packagePath + os + "/kelvin' -quiet -mem_ignore '" + java.io.File(prog.name).getAbsolutePath() + "'";

Sasha,

PFA

I am able to build the package in the target domain, but not in the Meta-Domain. "gmake test" is still not showing the o/p, I have attcahed the screenshot for your reference. Going ahead for own package implementation I have gone through the lesson given in the primer examples. How can I utilize them in CCS Project, i have tried with my example but in cfg file error is not propagated but when I build the packeage then error refelects.

Package build is also attached for your reference.

3872.lesson7.rar

3034.gmake test.docx

Abhishek,
I have replicated the first error, and I am looking for a fix. I'll let you know when I find something. In the meantime, you can try using the following workaround. Instead of typing 'gmake test', invoke the simulator directly:

C:examples\lesson1>"C:/Program Files/CCS_4.2.3/xdctools_3_20_08_88/packages/ti/platforms/sim64Pxx/Windows/kelvin" -quiet -mem_ignore prog.out

The second error is caused by backslashes, and you are also setting the path for the Gnu compiler to point to the location of gnu.targets package. But, that's not where a compiler should be installed. Have you installed the Gnu compiler and where is it located? If not, and you want to use only TI targets, you can remove the Gnu compiler from your list of targets. You do that by setting Build.targets to contain only C64P.

Build.targets = [C64P];

The third error would happen if you declare the function raiseHook in ErrLog.xdc file, but you haven't implemented that function in ErrLog.c. If you did implement the function, it's also possible that the libraries for that package do not include ErrLog.c. You can check Lesson 6 for a simple package.bld file that builds a library, and adds a module code to it.

Sasha,

raiseHook function declared in ErrLog.xdc is implemented in ErrLog.c as well as Library is also added in package.bld, it will be helpful for me if you have a look upon the Zip file of previous post.
same type of Error I experienced today as well.

PFA

inside zip file two packages are defined (these packages are implemented as given in "Extending xdc.runtime Logging/Example 1" in XDC user guide).

in doc file snaps of error experienced in CCS & it also covers app.c and app.cfg

3108.New Folder.rar5621.CONSOLE VIEW.docx

Abhishek,
the rar file from your last post contains two packages 'filters' and 'events' that are built for the C64P COFF target, and it appears that you are building the application for the C66 ELF target. COFF and ELF object files cannot be mixed. You have to either build 'filters' and 'events' for C64P ELF or C66ELF, or build your app for C64P COFF. The same problem exists in the ErrLog example in one of the previous posts. The package 'lesson7' is built for C64P COFF, and you are building the app for C66 ELF.

Have you tried the workaround I proposed for the lesson1, where you could not run 'xdc test'? I have found the bug that's causing the problem, but the fix will require a new XDCtools release.