ET_ILLEGAL_RESOURCE channel exception, XC calling C across tiles

Technical questions regarding the XTC tools and programming with XMOS.
bmc3
Junior Member
Posts: 5
Joined: Thu Nov 30, 2023 7:49 pm

ET_ILLEGAL_RESOURCE channel exception, XC calling C across tiles

Post by bmc3 »

Is it possible to have channel ends spanning tiles, with XC code on one end and C code on the other?
I've seen examples where an XC channel connects to XC across tiles, or C channel connects to C across tiles, but never one that connects from XC to C across tiles.
I've even seen an old post https://www.xcore.com/viewtopic.php?t=1847, from 2012, which teasingly offers a link to the solution, but the link is busted, perhaps because the info is way outdated. Channel code for C seems to have changed over the years; "xCORE C LIbrary" doc from 2016 looks outdated compared with current documentation for 15.2.1.

Background: I'm using xCORE-200 Multichannel Audio Platform, and modifying its predominantly XC code base so mixer.xc can perform some Software Defined Radio computation. I need to use multiple cores for the computation, so I ported (a stripped-down and modified) mixer.xc (which builds with 15.2.1 and works) to mixer.c, to make sharing memory much easier. mixer.c builds successfully along with everything else (using 15.2.1), and starts running, however I get ET_ILLEGAL_RESOURCE when mixer1() calls "request = chan_in_word(c_mix_aud);" (I renamed the chanends from the names in the original mixer.xc).

Program received signal ET_ILLEGAL_RESOURCE, Resource exception.
[Switching to tile[0] core[1] (dual issue)]
mixer1 (c_dcpl_mix=2147614722, c_mix_ctl=2147614978, c_mix_aud=2147615490)
at /home/bmcahill/HamRadio/4SquareTransceiver/XMOS/benbuild/sw_usb_audio_6.15.2_ben/sc_usb_audio/module_usb_audio/mixer/radio.c:256
256 request = chan_in_word(c_mix_aud);

To experiment, I also tried modifying the simple example in "Communicating between tiles", from the online XTC Tools Guide, Quick Start section, so one chanend is in XC, and one is in C, i.e. define main_tile0() in a file named main0.xc, and main_tile1() in main1.c. This also throws ET_ILLEGAL_RESOURCE, with a slightly different symptom, i.e. c=<value optimized out>. I'd be happy to provide my code, but please tell me how to embed/attach it ... this is my first post, and I can't find any info in the FAQ about embedding or attaching files.

tile 0: Result 0
xrun: Program received signal ET_ILLEGAL_RESOURCE, Resource exception.
[Switching to tile[1] core[0]]
main_tile1 (c=<value optimized out>) at ../main1.c:8
8 int iterations = chan_in_word(c);
Current language: auto; currently minimal

Help! :-0


User avatar
Ross
XCore Expert
Posts: 968
Joined: Thu Dec 10, 2009 9:20 pm
Location: Bristol, UK

Post by Ross »

Sounds like you might be trying to mix XC channel comms with raw channel comms via C. XC channel comms includes synchronisation etc. If you change the XC channel to a "streaming" channel then chan_in_word() should be able to receive the word send by c <: x. Going forward you will probably want to introduce a proper communications scheme i.e closing down the routes.
bmc3
Junior Member
Posts: 5
Joined: Thu Nov 30, 2023 7:49 pm

Post by bmc3 »

Thanks for quick response! ... Since I've been working with the XMOS source code for the xCORE-200 Multichannel Audio Platform, I had seen inuint() and outuint() in that code, so had tried using that for the XC side of my experiments with the simple example "Communicating between tiles", from the online XTC Tools Guide, Quick Start section. inuint() and outuint() failed, but trying c <: x and c :> y in the XC code (thanks to your response), things worked great with the C code's chan_in_word() and chan_out_word(), even *without* changing to "streaming" channel ... Yay! Got the tiny experiment working.

Now, however, for the real project, which is based on XMOS source code for the xCORE-200 Multichannel Audio Platform, I'm faced with interfacing a modified-and-ported-to-C version of mixer.xc (now called radio.c) with surrounding XC files audio.xc, decouple.xc, and audiorequests.xc ... they all use inuint() and outuint(), which I see, in xs1.h, are **incompatible** with the :> and <: operators ... and therefore, presumably, are incompatible with chan_in_word() and chan_out_word(), which I've used in radio.c ... therefore, the ET_ILLEGAL_RESOURCE.

Any advice?? Why was inuint() and outuint() used throughout the XMOS source code for the xCORE-200 Multichannel Audio Platform? Thanks in advance!!
magnus
Member
Posts: 13
Joined: Tue Aug 06, 2019 8:40 pm

Post by magnus »

edit: sorry, confused this with another topic.
Last edited by magnus on Mon Dec 04, 2023 2:11 pm, edited 1 time in total.
User avatar
Ross
XCore Expert
Posts: 968
Joined: Thu Dec 10, 2009 9:20 pm
Location: Bristol, UK

Post by Ross »

bmc3 wrote: Mon Dec 04, 2023 12:36 amWhy was inuint() and outuint() used throughout the XMOS source code for the xCORE-200 Multichannel Audio Platform? Thanks in advance!!
I think the original code pre-dates streaming channels being added to XC. It could very well of been the reason why they were added.. Sorry my memory is a bit hazy!
bmc3
Junior Member
Posts: 5
Joined: Thu Nov 30, 2023 7:49 pm

Post by bmc3 »

Okay, got it working!! Thanks for the insight into pre-streaming-channels history ... I take it that the xCORE-200 Multichannel Audio Platform code was "emulating" streaming channels, before they existed!

So others may know, I ended up modifying the ported-from-XC-to-C file only (did not change files remaining in XC), replacing each XC inuint() call with C s_chan_in_word() (note the "s_"); they both result in the same thing, which is simply an assembly code "in" instruction, *without* any preceding "chkct" nor "outct", and *without* any following "chkct" nor "outct", which, IIUC, are used in the non-streaming chan_in_word() to set up and tear down the channel each time called. Similarly, I replaced XC calls to outuint() with C calls to s_chan_out_word().

Note that the channels were allocated in main.xc as normal channels (not streaming channels), but since the surrounding code (in XC files, as well as the ported-from-XC-to-C file) was emulating streaming channels, the C "s_chan_" calls worked just fine, where my attempts at using "chan_" calls had caused ET_ILLEGAL_RESOURCE due to protocol mismatch (unexpected setup/teardown of channel).

Amazingly, this worked the first time I tried it ... Thanks for guidance!
User avatar
Ross
XCore Expert
Posts: 968
Joined: Thu Dec 10, 2009 9:20 pm
Location: Bristol, UK

Post by Ross »

bmc3 wrote: Mon Dec 04, 2023 6:03 pm . I take it that the xCORE-200 Multichannel Audio Platform code was "emulating" streaming channels, before they existed!
Exactly!

Glad you're up and running and thanks for posting for peoples future benefit!