• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 53 subscribers
  • Views 1084 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Compiler/IWR1443: cg_xml callgraph error

Brad Griffis
Guru*** 125430 points
Part Number: IWR1443
Other Parts Discussed in Thread: SYSBIOS

Tool/software: TI C/C++ Compiler

Here's my build environment:

  • Device: IWR1443
  • Cortex R4F
  • Compiler TI v16.9.4 LTS
  • cg_xml 2.60
  • sysbios 6.50.01.12
  • XDCtools 3.50.3.33_core

My project is generating an xml file as follows:

'Building target: level_sense_demo.xer4f'
'Invoking: ARM Linker'
"C:/TI/ccs_v7.3/ccsv7/tools/compiler/ti-cgt-arm_16.9.4.LTS/bin/armcl" -mv7R4 --code_state=16 --float_support=VFPv3D16 -me -O4 --opt_for_speed=0 --define=SOC_XWR14XX --define=SUBSYS_MSS --define=DOWNLOAD_FROM_CCS --define=DebugP_ASSERT_ENABLED -g --diag_warning=225 --diag_wrap=off --display_error_number --gen_func_subsections=on --enum_type=packed --abi=eabi -z -m"level_sense_demo.map" --heap_size=0x800 --stack_size=0x800 -i"C:/TI/mmwave_sdk_01_00_00_05/packages/ti/control/mmwave/lib" -i"C:/TI/mmwave_sdk_01_00_00_05/packages/ti/control/mmwavelink/lib" -i"C:/TI/mmwave_sdk_01_00_00_05/packages/ti/drivers/esm/lib" -i"C:/TI/mmwave_sdk_01_00_00_05/packages/ti/drivers/adcbuf/lib" -i"C:/TI/mmwave_sdk_01_00_00_05/packages/ti/drivers/crc/lib" -i"C:/TI/mmwave_sdk_01_00_00_05/packages/ti/drivers/dma/lib" -i"C:/TI/mmwave_sdk_01_00_00_05/packages/ti/drivers/edma/lib" -i"C:/TI/mmwave_sdk_01_00_00_05/packages/ti/drivers/hwa/lib" -i"C:/TI/mmwave_sdk_01_00_00_05/packages/ti/drivers/mailbox/lib" -i"C:/TI/mmwave_sdk_01_00_00_05/packages/ti/drivers/pinmux/lib" -i"C:/TI/mmwave_sdk_01_00_00_05/packages/ti/drivers/soc/lib" -i"C:/TI/mmwave_sdk_01_00_00_05/packages/ti/drivers/spi/lib" -i"C:/TI/mmwave_sdk_01_00_00_05/packages/ti/drivers/qspi/lib" -i"C:/TI/mmwave_sdk_01_00_00_05/packages/ti/drivers/qspiflash/lib" -i"C:/TI/mmwave_sdk_01_00_00_05/packages/ti/drivers/uart/lib" -i"C:/TI/mmwave_sdk_01_00_00_05/packages/ti/drivers/osal/lib" -i"C:/TI/ccs_v7.3/ccsv7/tools/compiler/ti-cgt-arm_16.9.4.LTS/lib" -i"C:/TI/ccs_v7.3/ccsv7/tools/compiler/ti-cgt-arm_16.9.4.LTS/include" --reread_libs --diag_warning=225 --diag_wrap=off --display_error_number --warn_sections --xml_link_info="level_sense_demo_linkInfo.xml" --rom_model --unused_section_elimination=on -o "level_sense_demo.xer4f" "./main.obj" "./source/demo.obj" "./source/iwr_gpio.obj" "../r4_linker.cmd" "../r4f_linker.cmd" -l"configPkg/linker.cmd" -llibesm_xwr14xx.aer4f -llibsoc_xwr14xx.aer4f -llibspi_xwr14xx.aer4f -llibqspi_xwr14xx.aer4f -llibqspiflash_xwr14xx.aer4f -llibpinmux_xwr14xx.aer4f -llibuart_xwr14xx.aer4f -llibmailbox_xwr14xx.aer4f -llibmmwavelink_xwr14xx.aer4f -llibmmwave_xwr14xx.aer4f -llibadcbuf_xwr14xx.aer4f -llibcrc_xwr14xx.aer4f -llibdma_xwr14xx.aer4f -llibedma_xwr14xx.aer4f -llibhwa_xwr14xx.aer4f -llibosal_xwr14xx.aer4f -llibc.a
<Linking>
'Finished building target: level_sense_demo.xer4f'

I'm attaching the xml file here:

level_sense_demo_linkInfo.xml

I'm trying to use the call graph tool.  First I tried it from windows using the executable included with the cg_xml tools:

C:\TI\cg-xml_2.60.00\bin>call_graph.exe C:\Users\a0193370\workspace_v7\level_sense_demo\Debug\level_
sense_demo_linkInfo.xml
Can't locate XML/LibXML/SAX.pm in @INC (you may need to install the XML::LibXML::SAX module) (@INC c
ontains: C:/TI/cg-xml_2.60.00/bin C:\Users\a0193370\AppData\Local\Temp\par-6130313933333730\cache-95
9081c80498894bc3c181730f981cd0e02355c6\inc\lib C:\Users\a0193370\AppData\Local\Temp\par-613031393333
3730\cache-959081c80498894bc3c181730f981cd0e02355c6\inc CODE(0x315ad0c) CODE(0x315af04)) at (eval 14
) line 1.
XML::Simple called at XML_TI_OFD.pm line 906.

Next I decided to copy the xml file over to my Linux PC.  Here's my attempt there:

brad@brad-XPS-15-9560:~/ti/cgxml-2.60.00/bin$ ./call_graph /mnt/diskstation/temp /level_sense_demo_linkInfo.xml
Use of uninitialized value $str in pattern match (m//) at XML_TI_OFD.pm line 220 4.
Use of uninitialized value $targ_num in hash element at XML_TI_OFD.pm line 1354.
./call_graph Only tested for C6000, C5500, ARM, C2000, and MSP430 not: unknown
Cannot find entry point. Stopped at script/call_graph.pl line 994.

Any ideas why I can't get a call graph?  As a side note, the "real" problem I'm trying to solve is why printf is included in my application, so I'm hoping the call graph will reveal where the phantom printf calls are originating!

Thanks,
Brad

  • 0
    TI__Guru**** 244930 points

    Two different errors are occurring.  One is a problem with cg_xml.  The other is mistake on your part.

    The cg_xml problem was first reported in this forum thread.  The root cause turns out to be deep in the details of how the Perl executables for Windows are generated.  This needs to be fixed, and another release generated.  Using the Linux executables is one workaround.  Another is to revert to cg_xml version 2.50.00.

    The mistake ... call_graph does not use the map file XML as input.  It uses the XML created by armofd.  Create it with a command similar to ...

    % armofd -xg --xml_indent=0 --obj_display=none,header,optheader,symbols,battrs --dwarf_display=none,dinfo file.out > file.xml

    That creates the smallest XML file, which means call_graph will run faster than otherwise.  If your program is not that big, or you just don't care, you can use this simpler command ...

    % armofd -xg file.out > file.xml

    Brad Griffis said:
    the "real" problem I'm trying to solve is why printf is included in my application

    That being the case, when you run call_graph, use the --func_info option.  That causes it to print out the file name of each function (among other things).

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    TI__Guru*** 125430 points
    Thanks, George. That worked! I also found the code that was responsible for calling printf. I may need to start a thread related to that one too. I'll have a go at it first...