UIA 2.0.0.28 redefined symbols and undefined symbol LoggerMin

I compared my configuration to the UIA Message Queue example and I've got the same configuration.

UIA 2.0.0.28, CGT 7.4.8, XDC 3.25.5.94, Sys/Bios 6.37.2.27, IPC 3.20.0.06

And I also get the same type of errors as shown in the attached output file.

3630.CCSv6_MsgQueLinkerError.txt

Cheers

The UIA staircase example links OK with the following configuration:

UIA 2.0.0.28, CGT 7.4.8, XDC 3.30.1.25_core, Sys/Bios 6.40.1.15

But when I try the same thing with the msg que example, I get the attached errors (a bunch of undefined symbols like _ti_sdo_ipc_gates_GateAAMonitor_enter__E )

UIA 2.0.0.28, CGT 7.4.8, XDC 3.30.1.25_core, Sys/Bios 6.40.1.15, IPC 3.20.0.06

2072.CCSv6_MsgQueLinkerErrorWithXdc3_30_01_25.txt

I also tried the new IPC. 3.22.0.05 and created a brand new msg que project using the canned examples from the wizard. Got errors about C647x? But I selected the C6472 EVM with the wizard.

I've checked the IPC compatibility matrix and believe I'm meeting the requirements shown below

UIA 2.0.0.28, CGT 7.4.8, XDC 3.30.1.25_core, Sys/Bios 6.40.1.15, IPC 3.22.0.05

http://downloads.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/uia/2_00_00_28/exports/docs/uia_2_00_00_28_release_notes.html

Now I think I've got a problem where I have to change from Coff to eabi since coff was removed in IPC 3.21.00.07. Back to IPC 3.20.0.06 for now.

There's another problem I just discovered when I changed the sys/bios. I de-selected 6.4 and then selected 6.37. Then tried to build. I immediately get the error below.

>> Compilation failure
1 fatal error detected in the compilation of "../message.c".
Compilation terminated.
gmake: *** [message.obj] Error 1
'Building file: ../message.cfg'
'Invoking: XDCtools'
"C:/ti/xdctools_3_25_05_94/xs"

Then I checked the RTSC configuration and behold, CCS has decided to use two sys/bios packages.

Bummer

Hi Eddie,

UIA 2.0 requires you to use XDC tools 3.30 (or higher) and BIOS 6.40 (or higher).  The libraries of this version of UIA were built with XDC 3.30, requiring you to use XDC 3.30.  Using an older version of XDC will cause the redefined LoggerMin symbols that you were getting. The problem you are facing with IPC, is that unfortunately, IPC has been built with XDC 3.25.  We do have plans to release an IPC version built with XDC 3.30, but this may not be before a few months.  In the meantime, I have a fix you can use.  I am attaching a linker command file that you can link with your project, that defines the symbols you need.

0714.fix_for_ipc.cmd.txt

Just add '-l fix_for_ipc.cmd' to your linker options.

Best regards,

    Janet

Hi

I've tried multiple combinations of IPC, SysBios etc when creating a msg queue project with the wizard for the evmC6472 with no luck. I've attached the project.

http://e2e.ti.com/cfs-file.ashx/__key/communityserver-discussions-components-files/355/3531.Eg_5F00_UiaMsgQueMultiCore2.7z

Thanks for your help in trying to find a working combination.

If possible, I'd like to stay with COFF as this will then be the configuration I'll use for our product as we migrate from CCSv4 to CCSv6 for our next big release.

Cheers

Hi

When I changed the configuration in the above msg que example project to

XDC 3.25.5.94, IPC 3.20.0.06, NDK 2.23.2.03, SYSBIOS 6.37.2.27, UIA 1.4.0.06 and XDAIS 7.10.0.06, CGT 7.4.8

and commented the first line and added second below to the .cfg 

//LoggingSetup.loggerType = LoggingSetup.LoggerType_RUNMODE;  
LoggingSetup.eventUploadMode = LoggingSetup.UploadMode_JTAGSTOPMODE;

it built. Yay! (don't know if it works however).

I then changed it to

XDC 3.30.1.25_core, IPC 3.20.0.06, NDK 2.23.2.03, SYSBIOS 6.40.1.15, UIA 2.0.0.28 and XDAIS 7.10.0.06, CGT 7.4.8

and got the errors below (it looks like IPC needs different components than the compatibility matrix specified for UIA 2.0.0.28 in

http://downloads.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/uia/2_00_00_28/exports/docs/uia_2_00_00_28_release_notes.html

**** Build of configuration Debug for project Eg_UiaMsgQueMultiCore1 ****

"c:\\ti\\ccsv6\\utils\\bin\\gmake" -k all
'Building file: ../message.cfg'
'Invoking: XDCtools'
"c:/ti/xdctools_3_30_01_25_core/xs" --xdcpath="C:/ti/ndk_2_23_02_03/packages;C:/ti/ipc_3_20_00_06/packages;C:/ti/bios_6_40_01_15/packages;C:/ti/xdais_7_10_00_06/packages;C:/ti/xdais_7_10_00_06/examples;C:/ti/uia_2_00_00_28/packages;c:/ti/ccsv6/ccs_base;" xdc.tools.configuro -o configPkg -t ti.targets.C64P -p ti.platforms.evm6472 -r debug -c "c:/ti/ccsv6/tools/compiler/c6000_7.4.8" --compileOptions "-g --optimize_with_debug" "../message.cfg"
making package.mak (because of package.bld) ...
generating interfaces for package configPkg (because package/package.xdc.inc is older than package.xdc) ...
configuring message.x64P from package/cfg/message_p64P.cfg ...
warning: ti.uia.sysbios.LoggingSetup: "C:/ti/uia_2_00_00_28/packages/ti/uia/sysbios/LoggingSetup.xs", line 85: ti.uia.sysbios.LoggingSetup eventUploadMode: The LoggingSetup.eventUploadMode configuration parameter has been replaced with LoggingSetup.loggerType. Will attempt to set LoggingSetup.loggerType based on eventUploadMode.
cl64P package/cfg/message_p64P.c ...
'Finished building: ../message.cfg'
' '
'Building file: ../message.c'
'Invoking: C6000 Compiler'
"c:/ti/ccsv6/tools/compiler/c6000_7.4.8/bin/cl6x" -mv64+ --abi=coffabi -g --include_path="c:/ti/ccsv6/tools/compiler/c6000_7.4.8/include" --define=c6472 --display_error_number --diag_warning=225 --diag_wrap=off --preproc_with_compile --preproc_dependency="message.pp" --cmd_file="./configPkg/compiler.opt" "../message.c"
'Finished building: ../message.c'
' '
'Building target: Eg_UiaMsgQueMultiCore1.out'
'Invoking: C6000 Linker'
"c:/ti/ccsv6/tools/compiler/c6000_7.4.8/bin/cl6x" -mv64+ --abi=coffabi -g --define=c6472 --display_error_number --diag_warning=225 --diag_wrap=off -z --stack_size=0x800 -m"Eg_UiaMsgQueMultiCore1.map" --heap_size=0x800 -i"c:/ti/ccsv6/tools/compiler/c6000_7.4.8/lib" -i"c:/ti/ccsv6/tools/compiler/c6000_7.4.8/include" --reread_libs --warn_sections --display_error_number --diag_wrap=off --xml_link_info="Eg_UiaMsgQueMultiCore1_linkInfo.xml" --rom_model -o "Eg_UiaMsgQueMultiCore1.out" -l"./configPkg/linker.cmd" "./message.obj" -l"libc.a"
<Linking>

undefined first referenced
symbol in file
--------- ----------------
_ti_sdo_ipc_gates_GateAAMonitor_enter__E C:\Work\CCSv6_ejp_m2_p4_0_integ_3\Eg_UiaMsgQueMultiCore1\Debug\configPkg\package\cfg\message_p64P.o64P
_ti_sdo_ipc_gates_GateAAMonitor_leave__E C:\Work\CCSv6_ejp_m2_p4_0_integ_3\Eg_UiaMsgQueMultiCore1\Debug\configPkg\package\cfg\message_p64P.o64P
_ti_sdo_ipc_gates_GateAAMonitor_query__E C:\Work\CCSv6_ejp_m2_p4_0_integ_3\Eg_UiaMsgQueMultiCore1\Debug\configPkg\package\cfg\message_p64P.o64P

>> Compilation failure
_ti_sdo_ipc_gates_GateMPSupportNull_query__E C:\Work\CCSv6_ejp_m2_p4_0_integ_3\Eg_UiaMsgQueMultiCore1\Debug\configPkg\package\cfg\message_p64P.o64P
_ti_sdo_ipc_gates_GatePeterson_query__E C:\Work\CCSv6_ejp_m2_p4_0_integ_3\Eg_UiaMsgQueMultiCore1\Debug\configPkg\package\cfg\message_p64P.o64P
_ti_sdo_ipc_heaps_HeapBufMP_getStats__E C:\Work\CCSv6_ejp_m2_p4_0_integ_3\Eg_UiaMsgQueMultiCore1\Debug\configPkg\package\cfg\message_p64P.o64P
_ti_sdo_ipc_heaps_HeapBufMP_isBlocking__E C:\Work\CCSv6_ejp_m2_p4_0_integ_3\Eg_UiaMsgQueMultiCore1\Debug\configPkg\package\cfg\message_p64P.o64P
_ti_sdo_ipc_heaps_HeapMemMP_isBlocking__E C:\Work\CCSv6_ejp_m2_p4_0_integ_3\Eg_UiaMsgQueMultiCore1\Debug\configPkg\package\cfg\message_p64P.o64P

error #10234-D: unresolved symbols remain
error #10010: errors encountered during linking; "Eg_UiaMsgQueMultiCore1.out" not built
gmake: *** [Eg_UiaMsgQueMultiCore1.out] Error 1
gmake: Target `all' not remade because of errors.

**** Build Finished ****

Hi Eddie,

You should be ok using UIA 1.04.06 with CCS6.  When you bring up RTOS Analyzer, you will see "Cannot Determine" written next to the items you check (eg, Execution graph). When you click on "Cannot Determine".  This should still be ok, though.  I've tried this with LoggerStopMode logs from UIA 1.03.01.08, and they looked ok.

If you really need to use UIA 2.0, though, then you will need to link with the linker command file I posted earlier, which defines the undefined symbols you are getting.

Best regards,

    Janet

Hi Janet

Thanks for helping

The reason I'm trying UIA 2.0 is because when I tried UIA 1.4 in our production code:

1)  the footprint for

ti.uia.runtime.a64P : LoggerStopMode.o64P

is almost twice the size of the RTA's

ti.targets.rts6000.a64P : System.o64P (.text:_xdc_runtime_System_doPrint__I)

so I hoped that the LoggerType_MIN would take less memory and still allow us to upload printf logs via JTAG. (unfortunately we are tight on SL2 memory)

2) I tried UIA 1.4 on our production code and I couldn't download the entire log. It said there were "gaps" in the data (sorry, I can remember the exact error).

I thought I'd use the trusted ol' Message Queue example to figure out what I need to do to get UIA 2.0 working, but that's been a challenge because the following has to be removed else UIA 1.4 tries to pull in transportNdk symbols. This is strange because I've eliminated all NDK from the .cfg and RTSC configuration.

var ServiceMgr = xdc.useModule('ti.uia.runtime.ServiceMgr');
ServiceMgr.topology = ServiceMgr.Topology_MULTICORE;

the link on this issue is posted here

http://e2e.ti.com/support/embedded/tirtos/f/355/t/345730.aspx

I'll try your command file and see how it works. Maybe I have to go back to UIA 1.4 and resolve the "gap" issue. But it still has a large footprint. A possible solution would be to put ti.uia.runtime.a64P : LoggerStopMode.o64P  into DDR2. Is this possible?

Cheers 

Hi Janet

I am able to run the msg que example without NDK successfully with the linker cmd you sent and adding the following line in bold

var ServiceMgr = xdc.useModule('ti.uia.runtime.ServiceMgr');
ServiceMgr.topology = ServiceMgr.Topology_MULTICORE;
ServiceMgr.transportType = ServiceMgr.TransportType_FILE;

But now the Tools->RTOS Analyzer->Printf and Error Logs tool says the Transport is "None"

and I get the error 

If I remove the service manager, the transport changes to Stop Mode JTAG. But the example no longer runs.

I tried changing the service mgr to single core and it still says transport is "None"

var ServiceMgr = xdc.useModule('ti.uia.runtime.ServiceMgr');
ServiceMgr.topology = ServiceMgr.Topology_SINGLECORE;
ServiceMgr.transportType = ServiceMgr.TransportType_FILE;

Cheers

Hi Eddie,

Sorry for not getting back to you sooner, but I got sidetracked onto another project.  I now have had time to test out this message example on 6472.  Since you want to use LoggerStopMode or LoggerMin, you don't need the ServiceMgr or NDK.  I'm attaching the message.cfg file that I modified to use LoggerStopMode.  I also changed the example to use just two of the cores, but you should be able to use more.

8814.message.cfg

You can diff your message.cfg with mine.   I was able to open RTOS Analyzer and see the execution graph and benchmarks.

Best regards,

    Janet

Hi Janet

No worries about the delay, I'm just glad you are helping. I've been a bit lost as to what to try next.

Your changes work well. I added log prints since this is what we use in our product. 

6763.message.c

and increased the size of to capture more logs

LoggingSetup.mainLoggerSize = 8192;

To see the log prints, I used the Tools->RTOS Analyzer->Printf and Error Logs. It creates a "*Live Session" and "*Printf Logs" tab. The "*Printf Logs" tab appears to display all cores. 

I couldn't figure out a way to clear the printfs other than closing the tab. I left the "*Live Session" tab open and then discovered the dropdown next to the Live Session "Analyze" button that allowed me to re-open the Printf Logs. By doing that, I can now open multiple printf log windows for selectively for each core. Yay.

Is there a way to 

1) clear the printf Log tab other than closing the tab?  This would be very handy so that you don't accumulate TONS of printf logs after each time you stop and start the cores.

2) configure the printf log window to default to display the SeqNo column?

Are the Time units in clock cycles or nsec like in CCSv4? I likes the way CCSv4 put commas in the numbers so it was easier to read.

I thought I was going to hit a home run until I tried to put the logs in DDR. I modified your message.cfg to have the lines in bold below. It works great without them. What am I missing? I'm still using MultiProc.setConfig(null, ["CORE0", "CORE1"]);. Should numCores=2 for it to work? I'll try after lunch.

Update (its after lunch now): Changing to =2 results in no logs at all (not even in the Live Session window). But changing back to =6 didn't even recover it back to where I could at least see core 1 logs. No logs. Nadda. The logs came back once I removed the bold text below. It looks like the logs can only exist in L2 for now.

var LoggingSetup = xdc.useModule('ti.uia.sysbios.LoggingSetup');
LoggingSetup.loggerType = LoggingSetup.LoggerType_MIN;

LoggingSetup.loadLoggerSize = 1024;
//LoggingSetup.loadLoggerSize = 8192;
//LoggingSetup.loadLoggerSize = 16384;
LoggingSetup.mainLoggerSize = 8192; // used for log prints
//LoggingSetup.mainLoggerSize = 32768;
//LoggingSetup.sysbiosLoggerSize = 32768;
LoggingSetup.loadLogging = false;
LoggingSetup.sysbiosTaskLogging = false;
LoggingSetup.mainLoggingRuntimeControl = true;

// Only use this if the buffer is in shared memory. We hope to do this
// when its in DDR.
LoggingSetup.memorySectionName = "DDR2";
LoggingSetup.numCores = 6; // tells logger that cores share a memory location.

Unfortunately only Core 1 logs show up now.  :o(

A question about MAUs, when we set the CCSv4 logger size to 256 MAUs, we got about 256 log records. But with it set to 1024 in CCSv6 UIA, we get about 39 log_print records. Do log prints in UIA2.0 take more memory?

Cheers (and thanks again for your help)

Update: I was testing your logger settings on our production code and came back to the msg Q example to check memory sizes. I've got it configured for loggers as in your original message.cfg but now I only see core 1 logs. Core 0 printf logs aren't present even though I know the codes executing because of the system_printf outputs. Arg. I reloaded and ran again, but this time, I got both cores. Yay. The tool seems very temper-mental.

Hi Eddie,

1. I didn't see a way to clear Log print statements from the RTOS Analyzer window.  You could post this question to the CCS form, because it seems like something that would be useful to have.

2.  You can see the sequence number in the "Live Session" window.  Was that not sufficient?

The time units displayed in RTOS Analyzer are in nano-seconds.  I agree, it is a bit difficult to read without commas.

I think LoggerStopMode sizes have always been in MAUs.  There are other loggers, eg, LoggerBuf, where the configured size is the number of records.  For a LoggerStopMode buffer of size 1024 MAUs, 39 records sounds about right.  LoggerStopMode uses variable sized events, and the average size is around 32 bytes.  The LoggerStopMode events should not take up more memory in UIA 2.0 than in UIA 1.x.  Could you have been using a different logger when you got the 256 records?

My message.cfg was missing the numCores assignment, so you if you are running a single image on all the cores, and the Logger buffer is in shared memory, you would need to set this.  Otherwise the Logs from the different cores will over-write each other.  Here's what I found in the LoggerStopMode documentation about numCores (Note that setting LoggingSetup.numCores will pass the value to LoggerStopMode):

     *  Warning: Setting this parameter to a value greater than one should only
     *  be done when there is a single image used on multiple cores of a
     *  multi-core device AND the logger instance's buffer is in shared memory.
     *  While functionally it will still work, memory will be wasted if both
     *  these conditions are not met.

I can believe that the tool may be temperamental at times.  Please feel free to report issues with this tool and improvements you would like to the CCS forum.

Best regards,

    Janet

Hi Janet

janet said:

I didn't see a way to clear Log print statements from the RTOS Analyzer window.  You could post this question to the CCS form, because it seems like something that would be useful to have

Posted it. http://e2e.ti.com/support/development_tools/code_composer_studio/f/81/t/348582.aspx

janet said:

2.  You can see the sequence number in the "Live Session" window.  Was that not sufficient?

Its harder to use in the "Live Session" window because it shows all cores.

janet said:

Could you have been using a different logger when you got the 256 records?

I think RTA specified the logger size in MAUs and not bytes like UIA does. I calculated that I needed about 8K bytes, then set that with the size parameter and it seems correct. The memory map also agrees.

janet said:

My message.cfg was missing the numCores assignment, so you if you are running a single image on all the cores, and the Logger buffer is in shared memory, you would need to set this. 

Yes, I used the settings below in your message.cfg. 

LoggingSetup.memorySectionName = "DDR2";
LoggingSetup.numCores = 6; // tells logger that cores share a memory location.

Unfortunately only Core 1 printf logs show up now in the "Live Session" window. If I remove the above code, the logs are present. Does this work for you?

Thanks for your help.

Cheers

Hi Eddie,

I'm not seeing Log data for any core in RTOS Analyzer when I use DDR2 for the section name and numCores = 2.  I'll look into this some more, but I suspect there is a bug either in RTOS Analyzer or UIA.  I can see Log events using ROV, although that doesn't look right either.

Thanks,

    Janet

Hi Eddie,

It turns out I forgot to set numCores = 2 in my test cfg file.  With that fix, I do get Log prints for both cores.  So it seems to work ok for me on two cores.  I will try more now.

Thanks,

    Janet

Hi Eddie,

I ran the message example with

    LoggingSetup.numCores = 6;

    LoggingSetup.memorySectionName = "DDR2";

and am able to get printf logs from all 6 cores.  I added Log_print's to the while(TRUE) loops tsk0_func and tsk1_func, which I see in RTOS Analyzer when I halt the cores. So, yes, this is working for me.

Are you using LoggerStopMode and not LoggerMin?

Thanks,

    Janet