CCS/TMS320C6657: HW-Breakpoints in C++ classes are not working for BINIT compressed code

Sven Mulka

Part Number: TMS320C6657

Tool/software: Code Composer Studio

Dear TI Support Team,

related tools:CCS 8.1.0 and CCS 7.3.0, compiler 8.2.3, PDK 2.0.9

I am running in an issue, where I can not set SW and HW breakpoints in my C++ code at runtime. After a long way of efforts I found out, that if I am using BINIT based compression of code (.text segment), where the code will be extracted at boot time, the setting of breakpoints in CCS debugger does not work anymore.

I can understand the issue for software based breakpoints, because the code will be changed at boot time, but I am using HW-breakpoints only and this does not work as expected. It looks so that the CCS debugger is not able to find the related debug information of LZSS compressed code sections (RUN address is unequal LOAD address) in the *.out file.

Please would you fill a bug entry in the SDOWP to track this issue.

Thanks and kind regards

Sven

over 5 years ago

0 desouza over 5 years ago

TI__Guru**** 168367 points

Sven,

Thank you for reporting this. However, to be able to fully reproduce this we will need a test case. If you have something that could be shared it would help speed up this process.

In the meantime, I will try to see if someone has something similar that could reproduce this here.

I apologize for the inconvenience,
Rafael

0 Sven Mulka over 5 years ago in reply to desouza

Expert 1162 points

Dear Rafael,

I have make a test project, which bundels some issues of linker, CCS debugger and RBL, which I have found in the last weeks.

For you is relevant the test in test_code_binit.cpp.

FYI: I am using the BINIT based compression of data and code sections in my project to save the space of my NOR flash. It works with some special action during the boot time. The binit table must be processed before any other runtime initializing like cinit or pinit.

Any feedback is welcome.

Kind regards

Sven

test.fill.zip

0 desouza over 5 years ago in reply to Sven Mulka

TI__Guru**** 168367 points

Sven,

Thanks for sending the testcase. The linker is refusing to compress the test_code.binit section (as shown below), thus any breakpoint I applied was normally hit.

<Linking>
warning #10247-D: creating output section ".tdata" without a SECTIONS specification
warning #10229-D: output section ".localfar" refers to load symbol ".init_array" and hence cannot be compressed; compression "lzss" is ignored
warning #10229-D: output section "test_code.binit" refers to load symbol "$C$SL1" and hence cannot be compressed; compression "lzss" is ignored
Finished building target: "C:/Users/a0356111/workspace_new/test.fill/Debug/test.fill.out"

The procedure I am following is shown in the short clip below; perhaps you may have any comments regarding the procedure?

Regards,

Rafael

0 Sven Mulka over 5 years ago in reply to desouza

Expert 1162 points

Dear Rafeal,

yes, outside of C++ classe you will be able to set the breakpoint, because that code is not loaded at runtime. Instead that please try to set a breakpoint in the function code_binit::run().

This function will be loaded at runtime and the CCS Debugger is not able to debug that function.

In general all code, which has different RUN and LOAD addresses, will be not debuggable in CCS.

The linker warning is only present in the test.fill project. In my real project the BINIT is using the LZSS compression. The warning is not relevant for the issue.

Kind regards

Sven

0 desouza over 5 years ago in reply to Sven Mulka

TI__Guru**** 168367 points

Sven,

Thanks, I was able to reproduce the inoperative breakpoint behaviour:

What strikes me is that the test_code.binit is not compressed at all (per the linker map file), thus I suspect something else other than compression is throwing the debugger off. (edit) nevermind. I can see the issue is with load/run and not compression.

I will keep investigating.

Regards,

Rafael

0 Sven Mulka over 5 years ago in reply to desouza

Expert 1162 points

Dear Rafael,

good news, that you can reproduce the issue.

As I have wrote, not the compression is the reason of issue, instead it is the loading of code during runtime from the LOAD to RUN address, see the app.cmd file.

I see two possible reasons for the issue:

a) the linker removes the DWARF information
b) the CCS debugger is not able to interpret the DWARF information

EDIT: Interesting is your second video. On my CCS v.8.1.0 the creation of breakpoint behaviour is someting different. First the creation of breakpoint will be disabled by CCS. If I try to enable it then a dialog pops-up with the information, that the test.fill.out file does not contain any reference to the source file and the breakpoint leaves disabled.

Thanks for your help.

Kind regards
Sven

0 desouza over 5 years ago in reply to Sven Mulka

TI__Guru**** 168367 points

Sven,

Yes, after I posted I noticed my mistake in assuming the root cause being the compression.

I filed today the bug report CCBT-2321 and in a few hours you can check its status in the link SDOWP in my signature below.

This is quite similar to the bug filed in the thread below, but one of the workarounds proposed (use HW breakpoints instead) is the subject of this thread.
e2e.ti.com/.../354642

I apologize for the inconvenience,
Rafael

0 Sven Mulka over 5 years ago in reply to desouza

Expert 1162 points

Dear Rafael,

thanks for filling the bug report.

HINT: It looks so that the issue only occurs with C++ member functions. Normal C-like functions are not affected by the BINIT issue.

My current workaround is to avoid the BINIT based code loading during the developing process. After finalizing the product, I re-enable the BINIT compression to save some space in NOR flash. For that I am using two macros in the app.cmd file to control the BINIT usage.

/***
 * Enable / disable compression of code
 *
 * WARNING:	If enabled then the setting of breakpoints
 *		in C++ code does not work.
 */
#ifndef USE_CODE_COMPRESSION
# define USE_CODE_COMPRESSION	0
#endif

#if USE_CODE_COMPRESSION
# define OPT_COMPRESS_CODE_LOAD(_load)		,load = _load, table(BINIT)
# define OPT_COMPRESS_CODE_RUN(_run)		run = _run
#else
# define OPT_COMPRESS_CODE_LOAD(_load)
# define OPT_COMPRESS_CODE_RUN(_run)		load = _run
#endif

The usage is something like that:

	/***
	 * Code sections in L2SRAM or MSMCSRAM
	 * Sections will be placed in L2SRAM or MSMCSRAM for faster access.
	 * Will be loaded at startup from .binit section.
	 */
	GROUP(code.fast) OPT_COMPRESS_CODE_RUN(MSMCSRAM)
	{
		xyz.code:fast	: palign = 128 OPT_COMPRESS_CODE_LOAD(DDR3)
		abc.code:fast	: palign = 128 OPT_COMPRESS_CODE_LOAD(DDR3)
	}

	/***
	 * Compress other code segment
	 * Will be loaded at startup from .binit section.
	 */
	def.code:slow : palign = 128, OPT_COMPRESS_CODE_RUN(DDR3) OPT_COMPRESS_CODE_LOAD(DDR3)

Kind regards

Sven

Code Composer Studio™︎

Code Composer Studio forum

CCS/TMS320C6657: HW-Breakpoints in C++ classes are not working for BINIT compressed code