Disabling System_printf when compiling for release mode

Sjf,

Here is a suggestion on how to tailor your configuration script based on your build profile. Although not directly related to your question about System_printf, it might still be helpful.

When you invoke the configuration phase with the configuro command, pass in your build profile from the make environment. Create a make variable which contains the build profile (i.e. PROFILE = release), then pass that to the configuro command using the --cfgArgs option.

$(XDC_INSTALL_DIR)/xs --xdcpath="..." xdc.tools.configuro ... --cfgArgs "{ profile: \"$(PROFILE)\" }" app.cfg

In your configuration script, inspect the cfgArgs object to figure out what build profile you are currently using.

var Program = xdc.useModule('xdc.cfg.Program');
var cfgArgs = Program.build.cfgArgs;

if (cfgArgs.profile == "release") {
    /* ... */
}

Are you building with a makefile or a CCS project?

~Ramsey

Thanks Ramsey for the response. I am building the application with a makefile.

I think what may have been causing my application to halt was the IAR semihosting linker option (--semihosting=iar_breakpoint), which was still used when building the release image. After removing this option from the linker command line, I then got a linker error saying that the __write function was unresolved (this issue was dealt with in this post). Instead of implementing the __write function, in release mode, I switched the System.SupportProxy in the cfg file to use SysCallback and implemented the five necessary functions, which now send the System_printf data out one of the UART ports (or optionally do nothing with the System_printf data). After doing this, my application now runs on the LaunchPad without halting after programming it using the LM Flash Programmer utility.

I used your method for setting up the cfg file for different build types.

if (Program.build.cfgArgs.profile == "debug") {

    // used when running in a debug environment    

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

    System.SupportProxy = SysMin;

    SysMin.bufSize = 256;

    TIRTOS.libType = TIRTOS.LibType_Instrumented;

    BIOS.libType = BIOS.LibType_Custom;

    BIOS.assertsEnabled = true;

    BIOS.logsEnabled = true;

  } else {

    // used when running without a debugger attached

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

    System.SupportProxy = SysCallback;

    SysCallback.abortFxn = "&MyPrintfAbort";

    SysCallback.exitFxn = "&MyPrintfExit";

    SysCallback.flushFxn = "&MyPrintfFlush";

    SysCallback.putchFxn = "&MyPrintfPutch";

    SysCallback.readyFxn = "&MyPrintfReady";

 

    TIRTOS.libType = TIRTOS.LibType_NonInstrumented;

    BIOS.libType = BIOS.LibType_NonInstrumented;

    BIOS.assertsEnabled = false;

    BIOS.logsEnabled = false;

}

The one question I have is whether it is possible to prevent System_printf from ever being called within NDK/SYS/BIOS to avoid the overhead of the call, or to remove all traces of System_printf. I thought I saw that by removing the following lines from the cfg file,

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

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

and using the following, this would globally remove System_printf. But it doesn’t appear to be the case.

TIRTOS.libType = TIRTOS.LibType_NonInstrumented;

BIOS.libType = BIOS.LibType_NonInstrumented;

BIOS.assertsEnabled = false;

BIOS.logsEnabled = false;

Do I just have to live with System_printf being called if using NDK/SYS/BIOS?

Thanks,

sf

sjf,
have you tried changing the debug level in your CFG script:
Global.debugPrintLevel = Global.DBG_NONE;

Can you give some examples of SYstem_printf messages that you are seeing? It's possible that there are some that are not controlled by the debug configuration.

Sasha, I've same issues (TI-RTOS, NDK stack on an AM3359 cpu).

I want to disable DbgPrintf info printouts, so I've added these lines in .cfg file:

Global.debugPrintLevel = Global.DBG_WARN;
Global.debugAbortLevel = Global.DBG_ERROR;

DbgPrintf is called through info_printf define wrapper

#define info_printf(...) DbgPrintf(1, __VA_ARGS__) /* level 1 = DBG_INFO */

After a total rebuild, I can't see any difference: informations are printed on log buffer (and sent through JTAG console in CCS v6).

Examining the value of _osenvcfg I see that the value of _oscfg.DbgPrintLevel is still 1 (=DBG_INFO)

Hints?

Eugenio,

Could you tell me what the value of "Global.enableCodeGeneration" is in your *.cfg file?  If this is false, then the settings Sasha suggested won't take effect.  This could be the reason you don't see your settings reflected in the oscfg struct.

Another possibility ... For your screen shot, at which point in the program did you take this?  Has the NDK started yet?  If you halted your app and took this screen shot before the NDK started, the configuration settings of your *.cfg file may not have been translated over to the oscfg struct instance yet.  You could verify this by waiting for your IP address to be obtained, then halt the app and check those values again.

eugenio said:

I want to disable DbgPrintf info printouts, so I've added these lines in .cfg file:

Global.debugPrintLevel = Global.DBG_WARN;
Global.debugAbortLevel = Global.DBG_ERROR;

The first issue I see here is that you set the "debugPrintLevel" to "DGB_WARN".  This means that you will see warning messages printed out by the NDK stack.  You need to set this to "Global.DBG_NONE" as Sasha shows above.
  You are probably still having issues due to the warning level messages being printed.

Steve

Steven, thank you for your reply.

I've changed debug level to DBG_NONE:

// NDK stack config
Global.IPv6 = false;
Ip.autoIp = false;
Ip.address = "10.11.18.35";
Ip.mask = "255.255.0.0";

Program.sectMap[".ndk_packet_buffer"] = new Program.SectionSpec();
Program.sectMap[".ndk_packet_buffer"].loadSegment = "DDR2(HIGH)";
Program.sectMap[".ndk_packet_buffer"].type = "NOINIT";
Global.pbmDataSection = ".ndk_packet_buffer:NDK_PACKETMEM";
Global.memDataSection = ".ndk_packet_buffer:NDK_MMBUFFER";

var http0Params = new Http.Params();
var http0 = Http.create(http0Params);
Global.debugPrintLevel = Global.DBG_NONE;
Global.debugAbortLevel = Global.DBG_ERROR;
Global.enableCodeGeneration = true;


var Telnet    = xdc.useModule('ti.ndk.config.Telnet');
/* add a Telnet server */
var telnetParams = new Telnet.Params();
telnetParams.callBackFxn = '&ConsoleOpen';
var telnet = Telnet.create(telnetParams);

After a rebuild, I see the console output with no change.

Debugging I can see that many messages are printed *before* NDK stack will initialize the _oscfg variable:

I've inserted an hardware breakpoint and I discovered that _oscfg is initialized in SPConfig function:

That function is called *after* NIMU hardware setup, so any DbgPrintf called inside hardware drivers (or os adaptation) will always see _oscfg.DbgPrintLevel=1.

I'll manually modify any DbgPrintf call to address this issue.

Problem still exists after _oscfg initialization: as you can see in previuos screeshot, value changes from 1 (=default at startup before NDK) to 3, that means DBG_ERROR, as defined in osif.h  (located in this folder C:\ti\ndk_2_24_03_35\packages\ti\ndk\inc\os ):

_extern void    DbgPrintf(uint Level, char *fmt, ... );
#define DBG_INFO        1
#define DBG_WARN        2
#define DBG_ERROR       3
#define DBG_NONE        4

This is not correct: I've selected DBG_NONE in .cfg file, so it should be 4. 

I've tested all configurations, and this is the result (first column=value in .cfg file, second column=value in _oscfg):

DBG_INFO	1
DBG_WARN	1
DBG_ERR	2
DBG_NONE	3

Eugenio,

I apologize for not responding sooner, this thread slipped through the cracks on me.

I tried to reproduce the issue, but I'm not getting the same result as you are.  I see that the DbgPrintLevel correctly starts at 1 and then gets the value of 4 after the call to SPConfig().

Can you try running the attached .out file?  It's just a slightly modified version of the tcpEcho example from TI-RTOS.  What values do you see for DbgPrintLevel?

That function is called *after* NIMU hardware setup, so any DbgPrintf called inside hardware drivers (or os adaptation) will always see _oscfg.DbgPrintLevel=1.

Yes, unfortunately this is true.  This is a know issue, being tracked already:

SDOCM00086985 NDK configuration values do not apply in NC_SystemOpen

Steve

The .out file is in the following zip file:

8360.tcpEcho_DK_TM4C129X_TI_TivaTM4C129XNCZAD.zip

Hi Steven. Thank you for your reply.

I've tried to run the .out file, but I get this error:

CortxA8: Loader: One or more sections of your program falls into a memory region that is not writable.  These regions will not actually be written to the target.  Check your linker configuration and/or memory map.

Maybe because my .gel file contains the memory map specifications needed by AM3359 cpu; I got it from AM3359 ICE demoboard software (with some minor modifications to handle an external fpga).

Eugenio,

My apologies. The .out file I gave you was for the TM4C1294XL ... I looked at the original post to see what board you are using:

"I’m using SYS/BIOS (version 6.42.01.20) with NDK (version 2.24.03.35) on the EK-TM4C1294XL LaunchPad, and am using IAR Embedded Workbench for ARM 7.2 for the compiler. Also using the DK-TM4C129X."

However, I see now that you didn't post that, and that you stated you're on the AM3359.  I'll have to find that board and give it a try there.

Steve

Eugenio,

Are you running a specific example? If so, which one?

Maybe it would be easiest if you zipped up and attached your sitara example here, so I could more easily reproduce what you are seeing.

Thanks,

Steve

I understand your point, but unfortunately I've never found an example for NDK and AM3359 cpu.

You can fine as attachment the .out file of my application (along with .gel file, for your convenience). it runs  on a custom AM3359 board with TLK110 as phy chip, connected to CPSW:

8561.ndk_dbg.zip

Ok thanks Eugenio. Are you using the Sitara SDK? That SDK has an NDK example. For example, I see it here in this version of the SDK:

am335x_sysbios_ind_sdk_1.1.0.4\sdk\examples\ethernetip_adapter

Steve

Yep, I've discarded that example because I suspected it was referred to EthernetIP industrial protocol only.

I've tested that project and _oscfg.DbgPrintLevel works as expected on my board. The problem is somehow related to NDK and SYS/BIOS versions.

Problem does not occur in EthernetIP project, where:

• XDC: 3.31.02.38
• SYS/BIOS: 6.42.2.29
• NDK: 2.24.3.35

Problem occurs using  TI/RTOS version tirtos_sitara_2_00_01_23, where:

• XDC: 3.31.02.38
• SYS/BIOS: 6.40.1.15
• NDK: 2.23.01.01

Now I've just changed my project from TI/RTOS back to SYS/BIOS with NDK (CCS6 names it in NDK Core Stack), picked the right NDK and SYS/BIOS versions, and the problem disappeared. 

Please, update TI/RTOS for Sitara, it seems a bit outdated.