RTOS/CC1310: How to enable logging for TI-Drivers?

M-W said:

Hi Eric,

You would have to also enable the "Log" module in TI-RTOS as the DebugP API wraps the Log API.

A quicker (and a method that does not add any code to the existing project) is to simply include the I2CCC26XX.c file into the project and step though it and find out what part of I2C_open that returns NULL. There is a few things that could cause this:

The I2C is already open or you have not called I2C_init.

The IO can not be initialized -> There most likely is a PIN conflict in the board file.

Could you try to step over it and see which of these causes the NULL return?

Thanks for this - I ended up figuring it out, I forgot to do Board_initGeneral() and I2C_init() et al.  After that my library works again.

But now I'm onto a different problem -- radio doesn't seem to work (got a troubleshooting procedure for that I will go through today), and I think it would be nice to have the ability to kick out those DebugP_log* messages for e.g. future SimpleLink SDK revisions that might alter the function of some drivers, or troubleshooting the use of drivers I've never used before - sometimes a hint from the driver is necessary to teach me what I'm doing wrong.

I did enable the Log module in the release.cfg fyi.  Does that automatically use System_printf() or whatnot?  How do you configure the Log module?

When you enable all of this, does the CCS compiler magically know to recompile the TI-Drivers from source instead of using the compiled library?  From what I can tell if the DebugP stuff is turned off, those DebugP_log1() et al compile to absolutely nothing.  Were the stock driver binaries compiled with DebugP on or off?  Or can we just do like you said--include specific TI-Drivers source files in our project to force them to implement DebugP_log* while ignoring the rest of the TI-Drivers stack (and letting it link from the distributed binary).

Hi Eric,

How the Log output is stored or displayed depends on the ILogger currently used. This could be for example the module LoggerBuf storing the information in an buffer or LoggerSys that uses System_printf functions: 

http://dev.ti.com/tirex/#/?link=Software%2FSimpleLink%20CC13x2%20SDK%2FDocuments%2FKernel%2FTI-RTOS%20Kernel%20Runtime%20APIs%20and%20Configuration

Have a look at the example, they give a somewhat good hint on how it all is put together (it is not super trivial).

When you have enabled all of this in TI-RTOS, the drivers are still not compiled with the debug statements. What you should be able to do is to add the driver source file of interest to the project in question. I will look into if there is something you have to do in addition to this.

Thanks... I see an example:

var Defaults = xdc.useModule('xdc.runtime.Defaults');
var Diags = xdc.useModule('xdc.runtime.Diags');
var LoggerSys = xdc.useModule('xdc.runtime.LoggerSys');

var LoggerSysParams = new LoggerSys.Params();
Defaults.common$.logger = LoggerSys.create(LoggerSysParams);
Diags.setMaskMeta("my.pkg.%", Diags.USER1, Diags.RUNTIME_ON);

So that goes into the TI-RTOS .cfg file, and then by default all modules log to that.  What would I put in place of "my.pkg.%" or should I ignore that line for debugging the TI-Drivers?

edit: Not sure after peeking around the XDCtools source if the Diags is even needed here, the TI-Drivers DPL layer just uses the XDC Log_* functions directly.

That logging infrastructure is some spaghetti mess!  I see now the concept of logging is pervasive throughout the RTOS and the log levels are defined by templates for their printf's...

Then there's this: http://processors.wiki.ti.com/index.php/CC26xx_Ouput_TI-RTOS_Log_statements_over_UART

That's pretty cool in that it uses the LoggerCallback to implement logging with ANSI color-styled templates for the different log levels.

I guess "Main" is applicable here to my code and to the TI-Drivers code as well?

// Turn on USER1 logs and INFO in Main module (user code). Turn off USER2 for fun.
Main.common$.diags_USER1 = Diags.ALWAYS_ON;
Main.common$.diags_USER2 = Diags.ALWAYS_OFF;
Main.common$.diags_INFO = Diags.ALWAYS_ON;

I tried my hand at just using a basic Log_info0() in my application.

Here's what I did with release.cfg:

var LoggerSys = xdc.useModule('xdc.runtime.LoggerSys');
var LoggerSysParams = new LoggerSys.Params();
Main.common$.logger = LoggerSys.create(LoggerSysParams);
Main.common$.diags_INFO = Diags.ALWAYS_ON;

Had to uncomment Diags for that.  Then in my main() function:

int main(void)
{
    pthread_t           thread;
    pthread_attr_t      attrs;
    struct sched_param  priParam;
    int                 retc;
    int                 detachState;

    /* Call driver init functions */
    Board_initGeneral();

    Log_info0("Hello world from Log_info0");

    /* Set priority and stack size attributes */
    pthread_attr_init(&attrs);
    priParam.sched_priority = 1;

    detachState = PTHREAD_CREATE_DETACHED;
    retc = pthread_attr_setdetachstate(&attrs, detachState);
    if (retc != 0) {
        /* pthread_attr_setdetachstate() failed */
        while (1);
    }
...

What ended up being printed to the console was:

[Cortex_M3_0] [t=0x00000000] {module#9}: {evt: 7, args=[0x4a60, 0x47 ...]}
smac_npi RTOS init-
smacnpi_controlTaskFxn begun

The [Cortex_M3_0] is always written but the [t=0x000.... stuff is new, and disappears when I comment out my Log_info0() line.  So I'm very close, but I'm not sure why LoggerSys(?) is displaying my Log_info0() text using an awkward display format like that instead of just printing text.

(The "smac" stuff is System_printf()'s from my main application thread)

Thanks!  That finally did it-

[Cortex_M3_0] [t=0x00000000] xdc.runtime.Main: [INFO: (../main_tirtos.c:71) Hello world from Log_info0]
smac_npi RTOS init-
smacnpi_controlTaskFxn begun
SMac opened
UART open
smacnpi Worker threads launched
smacnpi Begin UART read
smacnpi Control Thread Main Loop Begin