This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

How to read out loggerbuf content from ROV

Other Parts Discussed in Thread: SYSBIOS

Hi,

I would like to read out PEAK STACK SIZE using DSS debug server script. How to identify the address of the elements from ROV within the loggerbuf buffer?

I don't want to use the ROV gui. Rather to use DSS for automatically read the value

  • Thorsten,

    I've never tried this so I can only provide suggestions.

    In your application's config script make sure you define a Program.global variable for your LoggerBuf instance:

        Program.global.myLogger = LoggerBuf_create(...);

    From DSS you'll need to derefence the content of the 'myLogger' handle to determine the address of the LoggerBuf instance being used.

    At this address, a structure of the following type will be found:

    struct xdc_runtime_LoggerBuf_Object {
        const xdc_runtime_LoggerBuf_Fxns__* __fxns;
        xdc_runtime_IHeap_Handle bufHeap;
        __TA_xdc_runtime_LoggerBuf_Instance_State__entryArr entryArr;
        xdc_runtime_LoggerBuf_Entry* curEntry;
        xdc_runtime_LoggerBuf_Entry* endEntry;
        xdc_runtime_LoggerBuf_Entry* readEntry;
        xdc_Bits32 serial;
        xdc_Int16 numEntries;
        xdc_Int8 advance;
        xdc_Bool enabled;
        xdc_Bool flush;
    };

    The array of LoggerBuf entries is pointed to by the 'entryArr' element.
    The curEntry pointer is the address of where the most recent LoggerBuf event was written.
    The readEntry pointer is the address of the LoggerBuf event that will be read next by "LoggerBuf_getNextEntry()".
    The endEntry pointer is the address of the last element in the LoggerBuf entry array.

    Each of the LoggerBuf entries has the following structure defintiion:

    /* Entry */
    struct xdc_runtime_LoggerBuf_Entry {
        xdc_runtime_Types_Timestamp64 tstamp;
        xdc_Bits32 serial;
        xdc_runtime_Types_Event evt;
        xdc_IArg arg1;
        xdc_IArg arg2;
        xdc_IArg arg3;
        xdc_IArg arg4;
    };

    Figuring out how to decode each of the event entries may be a bit of a challenge. I'm not sure how to advise you on that.

    Alan

  • Another approach is to parse the *.rta.xml file that is generated. It contains the symbol name of the buffer and the size. For example:

      <loggers>
        <name>xdc.runtime.LoggerBuf.Instance#0</name>
        <type>xdc.runtime.LoggerBuf</type>
        <metaArgs>
          <bufferSymbol>xdc_runtime_LoggerBuf_Instance_State_0_entryArr__A</bufferSymbol>
          <bufferSize>2048</bufferSize>
        </metaArgs>
      </loggers>

    You can look at the serial number to handle wrap conditions. There are double entries you have to watch out for. For the description for LoggerBuf_write8 in LoggerBuf.c for more details.

    For decoding the entries...the *.rta.xml file also contains the event ids.For example.

    <evtMap key="ti.sysbios.knl.Task.LM_switch">
    <id>4576</id>     <msg>LM_switch%3A+oldtsk%3A+0x%25x%2C+oldfunc%3A+0x%25x%2C+newtsk%3A+0x%25x%2C+newfunc%3A+0x%25x</msg>
    </evtMap>

    The 4 args in the event record plug into the 4 0x%25x in the msg.

    Todd

  • Thorsten,

    After re-reading your question, I believe I've sent you off in the wrong direction.

    Determining the stack peak as shown in the Task's 'Detailed' ROV view can't be done by parsing LoggerBuf entries.

    I'll follow up with more details in a subsequent post.

    Alan

  • I think you can go to another option:

    Task_stat() will return the base address of the stack memory and its size. And you can populate it to the known global address. Configure your DSS script to get the address/size and check how many "0xbe" is stored at the top the stack. When you subtract it from the stack size, you would get the stack peak usage.

    Regards,
    Kawada 

  • Hi Kawada,

    thank you very much. The final answer can be a good fit. We just need to test it.

    Thank you