MCU-PLUS-SDK-AM243X: CCS refuses to locate the correct source-file for a function

Hello Felix,

Thanks for reaching out to Texas Instruments E2E support forum.

I have taken your inputs and working on it. Please allow some time to revert back.

Regards,

Tushar

Thanks Tushar,

I'd like to give you some more information I found:

So for the non-working-target it shows the path correct at least, in the modules view:

we can also clearly see in the disassembly that the compilation has our compiled code in it:

and now the working one, with the same code-base looks like this:

the path is nearly the same except of a different base-path but it uses the same git-submodules, same build-process etc.
I think the only difference we have a is a little-endian compiler-option but that's all. Of course the linker-script is arranged a bit different. What I missed to say: we use the tiarmclang LTS 3.2.0 compiler

I intentionally used the same debug-configuration in CCS for both, so it doesn't seem to be relied on this. And please keep in mind this seems to be the only location where this problem occurs. I tried to find functions of the SDK, as well as other of our functions of source files in the same folder. They all work. Ok, not all, some somehow open an cslr-file, but at least I can navigate to the functions and the symbols resolve and I can set breakpoints there.

Best regards

Felix

Hello Felix,

Thanks for the above infromation.

Can you please clarify what the working or non-working TI target means?

Can you please confirm that the path of the file does not contains any special symbols and whitespaces?

Please refer CCS Naming Convention.

Regards,

Tushar

Hey Tushar,

working target is the one which shows the correct symbol-resolves.

non-working is the one which cannot resolve the symbol correctly.

I can ensure that those paths do not contain any forbidden special characters. the base-path og the "non-working" only contains a "-" which is different to the working one, which contains none of them. But that's only for the base-path. Since our submodule-path contains "-"-characters and thus is the same for both targets I doubt that's the reason.

Best regards

Felix

Hello Felix,

Thanks for you response.

Felix Heil said:

I can ensure that those paths do not contain any forbidden special characters. the base-path og the "non-working" only contains a "-" which is different to the working one, which contains none of them. But that's only for the base-path. Since our submodule-path contains "-"-characters and thus is the same for both targets I doubt that's the reason.

Can you please share the exact path of both the files?

You can share it to me on private chat if you have any privacy concerns.

Regards,

Tushar

Hey Tushar,

I wrote you a message :)

Hi Felix,

If you use the "Locate File" button to explicitly browse to the correct file, does it work after that? Does it find the right file and you can set source line breakpoints correctly?

You also mentioned a working and non-working environment. They are loading the same executable and with access to the same source repository? What is the host OS for both? Looks like you are also using Windows Subsystem for Linux and that is where the source is. I assume you are using it for builds. Are you using CCS projects or a custom make environment (or both)?

Thanks

ki

Hey Ki,

yes I tried it, shortly the file pops up but immediately returns to the mentioned view.

It is not completely the same executable but a large part of the source-code is exactly the same, since it's our platform, which is included via a git submodule. So it's ensured they use the same commit for our "hw-support-package" which also contains the same MCU PLUS SDK. only the "project"-part is different.
And Yes we use wsl as an environment. To ensure compaitibilty we use th debug-prefix option:
"-fdebug-prefix-map=${CMAKE_CURRENT_SOURCE_DIR}=${WINDOWS_CURRENT_WORKING_DIR}" in CMake that way and add it as compile-option later on.
We are using a cutom make-environment for this, yes. It's CMake. The sdk is built via a separate command which just calls make. The CMake-projects just uses the built libraries of the SDK.
The abort-handlers would be present there, but declared as weak and later on will be overwritten by our handlers. This works as wen can see in the compiled image and the disassembly. And for the working one it also shows the related .cpp-file correctly.

Best regards
Felix

Felix Heil said:

yes I tried it, shortly the file pops up but immediately returns to the mentioned view.

I assume it opens that one time and then when you step or do some other target execution, it loses the source association.

I'll need some kind of test case to investigate further. I know this may be difficult to provide but I'm not sure how best further to proceed in debugging this issue. Ideally it is some stripped down version that is very simple. Almost some dummy program that uses your custom implementation for HwiP_prefetch_abort_handler. I would need the executable that was built and the source. Of course you can share via E2E private message if that is preferred.

Thanks

ki

Hey Ki,

I provided a link via an e2e-message. I also noticed that somehow the weak-declared abort-handler as well as our own implementation is compiled into the binary but only our implementation is called. We did compile everything with -ffunction-sections and -fdata-sections and it works for all the other stuff. Since this affects both binaries and one at least resolves the symbols correctly I guess that's not the main issue but may be another issue as well.

best regards

Felix

Thank you. Let's continue the discussion via private E2E message.