Corrupted LoggerSM logging and XDC runtime error: wrong type of return value:getDefaultTransport

Update:

Based on the example config at this site http://processors.wiki.ti.com/index.php/OMX_Viewing_Media_Controller_Traces, I tried adding this to my .cfg file:

ServiceMgr.transportType = ServiceMgr.TransportType_NULL;

This got rid of the build error message but I still see corruption in the DSP logs.

Annie Mac said:

Sometimes the messages from "dsp[0]" are clean and sometimes they aren't. It looks like memory is being stomped on

I'm wondering if Linux has been granted that memory used by the LOGGERSM section.  Could you please provide your 'bootargs' variable setting for Linux (can be retrieved using the Linux command '% cat /proc/cmdline').

If not that, perhaps you have caching enabled for that LOGGERSM section and it needs to be non-cached (just guessing, I'm not sure it does need to be non-cached).  The cachable setting for that LOGGERSM section @ 0xb2d00000 is controlled by MAR register 178, and to control that setting you would have configuration element in your DSP's .cfg file, something like:
    var Cache = xdc.useModule('ti.sysbios.family.c64p.Cache');
    Cache.MAR160_191 = 0x00040000;
Do you have any setting in your .cfg file for Cache.MAR160_191?  If so, it probably needs to be removed (MAR178 controls caching for 0xb2000000->0xb3000000).

Regards,

- Rob

Hello Rob,

I have no cache-related settings in my .cfg file.

# cat /proc/cmdline
console=ttyO2,115200n8 androidboot.console=ttyO2 vram=16M mem=128M@0x80000000 mem=640M@0xC0000000 vmalloc=700M
 eth=50:56:63:9e:09:a4 root=/dev/mmcblk0p5 rootwait init=/init

I have run another test and have looked at the contents of the memory at 0xb2d00000. I am going to attach a text file with the decoded ASCII values which come from the memory dump after pausing the DSP through JTAG. I also tried interpreting the decoded ASCII values. Please see the text at the end of the file. I do see segments of the logging which I want to see but I have shown the "logcat" output too and you will see that these segments do not show in the logcat output. I suspect the starting point of the place where the LoggerSM module tries to interpret strings is incorrect. Is that possible?

Thanks,
Annie

0601.memDump.txt

2480.memDumpImage.zip

Trying image attachment again.

Annie,

Thanks for analyzing all that output.

Your memory dump image is interesting.  In case you're curious, the beginning of that area at 0xb2d00000 is actually this object, defined in LoggerSM.xdc:
    /*!
     *  ======== SharedObj ========
     */
    struct SharedObj {
        Bits32 headerTag;
        Bits32 version;
        Bits32 numPartitions;
        Char *endPtr;
        volatile Char *readPtr;
        Char *writePtr;
        Char *buffer;
        Bits32 bufferSizeMAU;
        Bits32 droppedEvents;
        Bits16 moduleId;
        Bits16 instanceId;
        Bits16 decode;
        Bits16 overwrite;
    };
The values match up nicely, so we know that the memory dump is showing this state object.  One interesting note is that the "readPtr" and "writePtr" are both pointing to the same location - 0xb2d00708.  This reflects the fact that this LoggerSM instance is empty, and indicates the last area that was read by the 'logcat' tool (I assume).  It might be interesting to look at the values prior to 0xb2d00708 to see if they match the last thing output by logcat (and you can display the memory window as "character" to show ASCII).

Another interesting point is the coloring in the image.  Note the dark green starting at 0xb2d00280.  According to the boxes above the window, dark green is for L2 cache, meaning that the displayed values came from the L2 cache.  You indicated that there was no MAR cache config in your .cfg files, but that doesn't necessarily mean that something else isn't setting them.  Could you check the value of the MAR register at 0x018482c8 (if it is 1 then caching is enabled for 0xb2000000->b2ffffff)?

Regarding your .txt file dumps, it would be easier if you looked at memory in 8-bit character output.  Your "interpretation" is fixing a little-endian display issue, where every 4-byte word is reversed.

Regards,

- Rob

Robert Tivy said:

According to the boxes above the window, dark green is for L2 cache, meaning that the displayed values came from the L2 cache

I forgot to add that it might prove useful to uncheck that "L2 Cache" box at the top of the Memory window and see if the values in green change (other than the color, which will change to either white (not in cache) or blue (L1D Cache)).

Regards,

- Rob

Hello Rob,

Thanks for your reply. The value of the MAR register at 0x018482c8 is indeed 1. I will look at how to disable this.

Displaying memory in character mode! Doh! Why didn't I look for a handy shortcut like that?

I'll make some changes and do some more testing.

Thanks,
Annie

Thanks Rob. Your advice has fixed the issue  :-)

In my case I had to add this so that the existing config of MAR172 - 175 kept the value of 1:

var Cache = xdc.useModule('ti.sysbios.family.c64p.Cache');
Cache.MAR160_191 = 0x0000F000;

With this change the DSP logging displayed when "logcat" is run in the serial port is clean and solid. Yay!

Annie Mac said:

In my case I had to add this so that the existing config of MAR172 - 175 kept the value of 1:

var Cache = xdc.useModule('ti.sysbios.family.c64p.Cache');
Cache.MAR160_191 = 0x0000F000;

Great to hear, you're welcome.  That config looks right (although I'm sure you *knew* that, but it's a tricky config).

Regards,

- Rob