Problems with xTimeComposer

[LasOz]

Hello,

I'm having problems with xTimeComposer that I cannot resolve from following other threads on this topic and I would be very greatful if someone could help.

I've had xTC on my Windows 7 64-bit for a few weeks now and I have completed some small projects in it. The problem I have is I just opened it one day and got these (common) error messages:

"The xTimeComposer was unable to locate the XMOS toolchain binaries"


I went raking around on these forums for a solution and found it had something to do with a certain bat file. So I uninstalled xTC and reinstalled it (making sure I had admin permissions) then ran the bat file. I got the same error messages. I then uninstalled xTC and tried a different install location (Program Files instead of Program Files x86) and ran the bat (trying it a few times just to make absolutely sure it had ran).



xTC then started working correctly again and I got started on a new project. I ran a test or two on a program I had written and it worked as normal. Then the program became incredibly laggy, which I thought may have been other process on my computer. I opened task manager to find my CPU usage at 100% and xTC was barely responding to any commands. So I closed xTC and re-opened it. Guess what.



I'm out of ideas at this point. Could anyone please help me with this issue?

[sethu_jangala]

In the xTIMEcomposer folder, you will have a file called SetEnv. If you are running the tool from the command line, First you need to run the SetEnv file and then run the xtimecomposer application.

This should solve your issue.

[xuhx]

S'cuse the necro, but I think this is the newest thing that most closely resembles problems I've got with xTimeComposer.

I've been trying to get (community) version 13.2.2 to run under win8.1; intermittently I've been getting exactly those error messages. Not on the first run (I've uninstalled and reinstalled about 6 times), but every run thereafter it's a roll of the dice. Trying to run SetEnv.bat, even with admin rights, does nothing to set the environment variables itself. Even "call"ing it from a cmd line, then echo'ing back what it's created and hand-pasting them into the environment variables myself, it gets rid of the "environment variables are not set" error, but not the "can't find the toolchain".

On top of that, when it does work that far, it won't build anything more complicated than the basic example projects. I've a multi-section project that fails every time with the "Unable to open output file [...] for writing elf" error others have seen. Supposedly the workaround is "add the missing directories that the compiler is meant to create but isn't", which should not be necessary and is very much unworkable for anything with a half dozen modules and growing.

And even with the directories in place, it still can't build the project properly because the installer never installed xmap. At all. Every installation I've checked, and it's always been missing from the bin directory, wherever it's installed, with or without admin rights, and after redownloading the installer too. (This I though could have explained the "can't find the toolchain" error, but then that error is intermittent, not there every time.)

Have I just been particularly unlucky, or is xTimeComposer just completely borked under win8.1? Under OSX xTimeComposer installs and builds exactly the same project from scratch, without issue, first time. Both from the terminal with xmake and from the GUI. Under win8.1 xTimeComposer is currently entirely unusable for me. (NB: Version 14 doesn't have these particular issues, but still fails to build the project; I need version 13.x for the versions of libraries targeted.)

[Guest]

Can you check if the antivirus or firewall of your machine is blocking the xmap or xtimecomposer files. Disable antivirus and try again.

[xuhx]

*uninstall* *manually delete xmos install folder*
*disable antivirus* *reinstall to C:\XMOS\xTIMEcomposer\Community_13.2.2*

That's at least installed xmap this time; thanks. I hadn't expected the install to just silently mess up like that ... an error message from it somewhere along the line would've been nice. You think it would at least notice the complete lack of various essential executables.

I've also not seen the return of the environment variable or toolchain errors yet (restarting the IDE a few times) ... but given how patchy they've been I'm still not convinced that's entirely squashed.

The project still doesn't compile, though. I'm still getting this error on the first module:

Code: Select all

Using modules: <<omitted>>
Compiling <<filename>>.c
ERROR: Unable to open output file '../.build_Release/src/<<filepath>>/<<filename>>.c.o' for
writing elf
xmake[3]: *** [.build_Release/src/<<filepath>>/<<filename>>.c.o] Error 1
xmake[2]: *** [bin/Release/<<projname>>.xe] Error 2
xmake[1]: *** [bin/Release/<<projname>>.xe] Error 2
xmake: *** [bin/Release/<<projname>>.xe] Error 2

<<filename>>.c is there, but it's not creating <<filepath>>. If I put it there myself, it just fails on the next path for the next module. As mentioned, exactly the same project builds under the OSX version of xTimeComposer 13.2.2.

[Guest]

Can you try doing a clean project and rebuild the project. Have you tried building any of other example projects or application note examples?

[xuhx]

After a quick recovery of xmap.exe from the antivirus again (it turns out it *does* consider it a virus, it was just being quiet about removing it) and adding it to the antivirus exclusion list along with the xmos and workspace folders, I tried a number of the startKIT Examples projects.

Noughts and Crosses (app_noughts_and_crosses), Glowing LED Pattern (app_glowing_leds) and The spinning bar (app_spinning_bar) all look like they build correctly; e.g. for noughts and crosses:

Code: Select all

Creating app_noughts_and_crosses.xe
Constraint check for "tile[0]" (node "0", tile 0):
  Cores available:            8,   used:          2 .  OKAY
  Timers available:          10,   used:          3 .  OKAY
  Chanends available:        32,   used:         11 .  OKAY
  Memory available:       65536,   used:      21556 .  OKAY
    (Stack: 3392, Code: 16972, Data: 1192)
Constraints checks PASSED.
Build Complete

Similarly, the examples "How to use channels between cores" (app_simple_core_channel_communication_Example, 1.1.1rc0) and "Touch Screen Demo" (app_touch_controller_lib_demo, 1.1.2rc0) build fine.

The Startkit Dalek example (app_audio_dalek) fails for reasons likely unrelated to the problem we're looking at:

Code: Select all

Compiling audio_io.xc
../src/audio_io.xc: In function `audio_hw_init':
../src/audio_io.xc:59: error: incompatible type for argument 1 of `i2c_master_init'
xmake[1]: *** [.build/src/audio_io.xc.o] Error 1
xmake: *** [bin//startkit_dalek.xe] Error 2

Our own project still fails in the same place as before, after not only a clean, but a complete deletion and re-cloning from git.
However, if I manually create the 20-odd nested folders in .build_Release for it, it does eventually build correctly (!). Then those folders are going to be nuked the moment I clean the project again. :| So it looks like now the only problem is xTimeComposer refusing/failing to produce any folders in .build_Release or any sub-folders in there (I tried rebuilding after just adding a base folder in .build_Release too, but it wouldn't create any further folders).
In case it's a strange pathname thing preventing folder creation, my usual path has a '.' in the name, but no other non-alphanumeric characters, nor spaces. I did also try in an alternate path without the '.' but it still failed to build the same way.

[Guest]

Not sure whats causing issue in your case. Can you please file a support ticket on XMOS website. They should be able to provide you with an alternate solution. You can file the ticket from the following link:(Report a bug section)

https://www.xmos.com/support/support

[xuhx]

:D Fair enough; I'll get a ticket filled out.

Thanks for your efforts so far, though - your suggestions managed to fix most of it, enough to get it to build (at last) with a little manual help, just not that last issue to automate it properly.

[Guest]

:D Fair enough; I'll get a ticket filled out.

Thanks for your efforts so far, though - your suggestions managed to fix most of it, enough to get it to build (at last) with a little manual help, just not that last issue to automate it properly.

Please update us if you get any fix from XMOS. The fix from XMOS will be useful for other community users who are facing similar issue.