TDA4VM: CCS can not resolve source to various PDK components

Hi Thomas,

Are you able to build your projects with PDK component?

Thomas Dorsch said:

I had several problems doing this toolchain switch. The main remaining one is, that during debugging with CCS, the source code stepping does not work anymore for PDK components.

What issue are you facing with single stepping? Are you not able to locate the file while debugging with PDK components or not able to single step through those files?

Regards,
Parth

Hi Parth,

Parth Nagpal said:

Are you able to build your projects with PDK component?

Yes, we are now able to build our projects with PDK 08_02.

Parth Nagpal said:

What issue are you facing with single stepping? Are you not able to locate the file while debugging with PDK components or not able to single step through those files?

While debugging I can single assembly step through all the code (including PDK components).

However, I can not single "c-source" step through the PDK components code. But I can c-source step through my own project code.

In my post above, I picked the "sciclient" as PDK component example. I can step through the assembler code, but CCS does not show me the c-code. So I cannot step through c-source code.

My assumption is, that the the built PDK components in version 08_02, somehow miss the path information where the c-source files are located. I tried to illustrate this with the first two pictures.

In the first, you can see that the absolute path (compilation path) is embedded (PDK 08_00). In the second, you can see that only a short relativ path (compilation path) is available.

I think, based on this, CCS struggles while debugging to resolve the assembly code to c-source files. And as result "c-source" stepping on PDK components is not possible anymore.

However, I think its crucial for us to be able to debug PDK components.

Best regards,
Thomas

Hi Thomas,

Apologies for long delay in response. Can you please share the build options you are using to build your project?

Regards,
Parth

Hi Parth,

again, the build option of my project do not matter here. Let's reproduce a simple example that we both have access too:

1. Build the udma_memcpy_testapp for mcu2_0 in debug mode:
thomas@dt-tda4:~/tda4vmx/psdk/pdk_jacinto_08_02_00_21/packages/ti/build$ make -s udma_memcpy_testapp_freertos BOARD=j721e_evm CORE=mcu2_0 BUILD_PROFILE=debug

2. Load the .xer5f on mcu2_0.

I configured my emulator to stop at main function, after the application has been load to the target cpu and started.

I can now single step through the c-code of main_rtos.c. This works, because the compilation path of that file is correct at the modules view:

Now at line 99 for example, c single step into "OS_init()" could not get resolved by CCS, because the compilation path information is just a relativ path with 2 hierarchies up.

This is the same for EVERY PDK component! Drivers, FreeRTOS, csl, osal whatever.

And this has been changed between ti-psdk-rtos-j721e-evm-08_00_00_12 and ti-psdk-rtos-j721e-evm-08_00_00_12.

Can you confirm this on your side?

Best regards,
Thomas

Hi Thomas,

I am can see the same issue as you mentioned. But in such cases you can always use the locate file option to locate the source code. And then you can proceed with single stepping through that. Have you tried that option? Are you facing any issue with that?

Regards,
Parth

Parth,

yes that would work. However in my eyes, thats not a practial solution. The current pdk/packages/ti contains about 22k files.

I cannot solve over hundreds of c-files per hand for a CCS debug session! Over and over again.

What is the problem? Why can TI not fix this? I don't understand...

Best regards,
Thomas

Hi Thomas,

Thomas Dorsch said:

I cannot solve over hundreds of c-files per hand for a CCS debug session! Over and over again.

You don't need locate all the files. For most of the files the path will be resolved and for only some files you'll need to locate the path manually. This should not be a blocking issue for you.

Meanwhile, I am also checking this on my end and will get back on this by end of this week.

Regards,
Parth

Hi Parth,
Could you find a workaround?
Can you create a JIRA entry for this (and share the number) so that this gets fix in the future?
Thanks in advance,

Anthony