LoggerSMDump not returning (no logs being read)

ferric said:

LoggingSetup.sysbiosTaskLogging = false;
LoggingSetup.sysbiosSwiLogging = false;
LoggingSetup.sysbiosHwiLogging = false;
LoggingSetup.mainLogging = false;

You've disabled all logging with the above lines, so there with be nothing logging into LoggerSM.

What do you mean that you've commented out the offending function?

Todd

Thanks Todd for the quick reply.

I meant that in UIAMetaData.xs (located in .../ti/uia/runtime), I made the following change:

cpuFreq = 300; /*BIOS.getCpuFrequency();
I wasn't too concerned about the accuracy of the timestamps, therefore I just put a dummy value for cpuFreq instead of making the actual call. Hope I haven' misunderstood what this code is supposed to do. (?).

I'll modify my cfg file like you suggested.

Thanks.

Still no luck. I've set the following lines to true (they were false before):

LoggingSetup.sysbiosTaskLogging = true; /*false; */
LoggingSetup.sysbiosSwiLogging = true; /*false; */
LoggingSetup.sysbiosHwiLogging = true; /*false; */
LoggingSetup.mainLogging = true; /*false; */

I still dont get any logs out from the loggerSMDump application.

Is there something else that looks wrong in my .cfg or source code?

Why do you have the ServiceMgr included? This module is only used to help move logs off the processor via some physical connection.

Why are you explicitly only having Defaults.common$.diags_USER1 on? LoggingSetup defaults the Diags mask unless the user has explicitly set them, like you have.

I guess the real question is what Log events are you trying to get? Task? Load? Your own?

Todd

At the moment, I am only trying to get my own logs out, by adding Log_printn( ) commands in the source code. For example, I have the following line in my main function:

Log_print0(Diags_USER1, "--> main:");

Thanks for looking into this.

Ferric

I tried out your configuration and the record was added. What makes you think it is not being written? Here is the memory buffer.

Here are the meanings for the highlighted values:
First highlighted value: 0x20001080 = readPtr.
Second highlighted value: 0x20001094 = writePtr
Third highlight values: Log record...the 0x349c is a pointer to the "--> main:" string.

Please note you should move to UIA 1.04.00.06. There is a bug with LoggerSM_write2. Or you could fix the offending line and rebuild your current UIA.

The fix for SDOCM00103804 to went into 1.04.00.06 was to add the following bolded line into LoggerSM_write2 in the  packages\ti\uia\runtime\LoggerSM.c file.

        myWrPtr = fillInEventHdr((Bits32 *)LoggerSM_module->sharedObj->writePtr,
                      numBits8ToWrite, LoggerSM_module->serial++);
        *(myWrPtr++) = ((evt) & 0xffff0000) | mid;
        *(myWrPtr++) = a1;

Todd

Thanks a lot for your help Todd.

I have modified LoggerSM_write2( ) like you suggested above, and recompiled my app, but I am still getting the same problem. (I am assuming that I don't need to recompile the LoggerSMDump utility. ). I cannot upgrade UIA because that would require sys/bios version 6.35 or later (http://e2e.ti.com/support/embedded/tirtos/f/355/p/356220/1249703.aspx).

Maybe I am doing something wrong on the source-side (not including some header file perhaps?).

Thanks once again.

Can you confirm the records are in the shared memory on the target. Open a Memory browser and look for ti_uia_runtime_LoggerSM_Module_State_o_sharedBuffer__A. You should see records similar to my picture that I attached.

Todd

I do not have a CCS instance running as our setup is currently based on command line tools only. I only have the loggerSMDump utility to read the memory contents.

One more thing; I said in my previous reply that I had done the bug fix you suggested but it didn't make any difference. I was under the impression that I could simply modify the LoggerSM.c file (in /ti/uia/runtime/ folder) and rebuild my app. But I now realise that perhaps I need to rebuild the UIA modules before rebuilding my app. Is that correct (i.e. do you think I need to rebuild UIA in order for the bug fix to take effect)?

I have also noticed that even when I set LoggerSM.decode = true in my cfg file and rebuild my app, the LoggerSMDump utility still thinks that the logs are encoded and opens a LoggerSM.bin file for storing the logs. I thought that the logs would have been stored in decoded form and would simply be displayed on the console. Something's not quite right in my setup.

Ferric

Hi Ferric,

You need to rebuild the UIA library. Sorry I did not make that clean enough. Take a look in the TI-RTOS User Guide for instructions on how to rebuild products within TI-RTOS (e.g. gmake -f tirtos.mak uia).

I'll send you a modified LoggerSM.bin that dumps the first N words of the memory. We can look at that to figure out exactly what is going on. Just to make sure, which version of UIA are you using?

Todd

Thanks Todd. I am using UIA_1_03_00_02.

I did try to rebuild UIA this morning by following the instructions in Section 6.3 ("Rebuilding Target-side UIA Modules") in spruh43d ("Spectrum Analyzer UG"). The compilation stopped when it couldn't find the "ti.sysbios.knl.Semaphore" . Below is the exact error message:

Just an update on the last sentence in my previous post: I can't find the tirtos.mak file on my machine. I inherited this machine from a colleague and all the tools (IPC, XDCtools, Syslink, sys/bios etc) are installed seperately (i.e. not as part of a unified "TI-RTOS" installation).

Therefore, my only option is to follow the instructions in spruh43d and use the uia.mak file. But this results in the error I mentioned in my previous post.

Can you post the uia.mak and uia.bld files you are using and the exact command you are running?

The files are attached. The exact command is: make -f uia.mak

(This is based on Section 6.3 in spruh43d)

Can you try this new library (I added the .pdf to avoid the forum police)? 5658.loggersm.a.pdf

Rebuild loggerSMDump.out with the new library and run it. This will dump out the contents of the shared memory. Please ntoe I have not tested it...I'm tracking down a board to verify it.

Todd

Hi Todd

Thanks for sending me the library, at last I can see what's being stored in the memory.

The log buffer output is attached (. Each entry originally had 6 zeros at front, which I have removed. For example, the third entry was '00000014', which I have truncated to 14. I've compared to the memory dump you posted earlier in this thread but couldn;t see any similarity or any helpful pattern.

Ferric

Hi Todd

I am closing this thread now as my immediate problem has been resolved. Would it be possible for you to send me the source code for the modified loggerSM.a library that you sent me earlier in this thread (5658.loggersm.a.pdf).

Thanks a lot for your help.

Ferric