CCS/CC1310: recipe for target '../src/sysbios/sysbios.aem3' failed

Hello Jan,

Are you working with the same version of XDC tools, SDK, and CCS as before? If not I would start by recreating the same environment as the one where the project was working on before.

If the working environment is the same as before, I would make sure the main project is pointing to the correct TI rtos project as a dependency. This can be done by right-clicking properties->build->dependencies.

If this is also correct, the next step should be importing a fresh copy f the ti-rtos project and rebuilding.

I hope this helps you out,
AB

Thank you. The original post is being replied to, see: e2e.ti.com/.../2485031.

> Are you working with the same version of XDC tools, SDK, and CCS as before?

In principle yes, as the original project had the latest versions installed. But that apparently didn't mean the project was using them, as it opened on the new PC trying to use xdctools_3_50_03_33_core, which was not present. So in my understanding it then tried to use 3_50_04_43_core. It strangely didn't allow us to modify this to 3_50_04_43_core (without trying xdctools_3_50_03_33_core). It kept reverting back. Only after setting to xdctools_3_32_00_06_core and then back to 3_50_04_43_core did the setting stick.

I'll follow your instructions later on, as I will have to go through the whole procedure: update original project, discover the secrets involved, commit, checkout, new workspace, import. All the stuff I'd prefer to live without, and which may easily generate new potholes.

Wouldn't you be able to say how the IDE fails given the above image? For that would give me an idea why it fails (if it isn't a bug).

---

<rant>
I bet this is an easy error for you folks to resolve, given access to my machine. It's almost 2020: why doesn't an IDE download and recreate its dependencies? If it must create trouble anyway, why not have a tool that checks for inconsistencies and resolves them? If we must have a forum, why not have a tool that collects the info support needs, so it can analyze the situation, properly, and provide a patch? In the end it'll have a toolbox of patches and I'll be able to just run them.

I see (and am involved in) a fallacy here: you use me as the mostly fallible interface to a system which you could assess, with code, in a precise and reliable way. Seems malevolant to want to use me instead...?? Support does not seem to realize that it should say those things, it asks of me, to a computer. If it did, easy peasy: it gets the info it wants, and it can then emits the actions it wants, ask me to apply them. Problem solved, case closed, lesson learnt. Takes 3 minutes tops in 90% of the cases, from the moment the problem occurred to the moment it was solved. And I could get on with my job.

Why do things the hard way? Why insist on doing things the wrong way? Is that your job? If you write code, you are sure to identify and describe the problem. It also makes for an excellent bug report.
</rant>

Ok, thank you.