xrun -l output Topic is solved

[ejolson9]

Hello,

I am trying to bring up a newly assembled pcb with an xmos on it. The first thing I'm trying to get working is the xscope debug printfs. When I connect to the board with an xtag-2 and run the command "xrun -l", I get the following output:

Code: Select all

Available XMOS Devices
----------------------

  ID    Name                    Adapter ID      Devices
  --    ----                    ----------      -------
  0     XMOS XTAG-2             xXNUvdh_        O[0]

Does anyone know what the "O[0]" implies? I'm used to seeing something like this from the slicekit:

Code: Select all

Available XMOS Devices
----------------------

  ID    Name                    Adapter ID      Devices
  --    ----                    ----------      -------
  0     XMOS XTAG-2             xXNUvdh_        L[0..1]

Do "L" and "O" mean anything different? I'm having difficulty getting xscope printing to work on this board (works on slicekit) and I thought this might be related. There doesn't seem to be any note of this in the xrun command line manual.

Thanks
Erik

[infiniteimprobability]

L[0..1] means a network of 2 x L devices. Each L device is a node (has it's own switch), consisting of one tile.

O[0] means a network of 1 x O device. Each O device is a node (a switch) consisting of two tiles.

These details are described in the .xn XML file which shows the hierarchy of the chips.

So from a JTAG point of view, everything is as it should be. Your device is powered up and the TAP controller is visible to the XTAG.

Xscope is independent of JTAG. So, at first glance, it would suggest there is an issue with the 2 x 2-wire xCONNECT Link lines. Check the connection of these - are they reversed? This section of the datasheet is worth double checking H.3 Full xSYS header/ I am assuming you have xscope enabled using the config.xscope file with the line

Code: Select all

<xSCOPEconfig ioMode="basic" enabled="true">

Finally some history -L = "Low power", which is relative to "G" - the older "General purpose" devices
"O" stands for outrun, which is the internal name for xcore 200. So O and L are names of the particular silicon die inside the device.

[ejolson9]

Thanks for the info, it's good to know the device looks fine. I had thought the "L" might have stood for link or something.

Check the connection of these - are they reversed? This section of the datasheet is worth double checking H.3 Full xSYS header

Yes I've checked these and the hardware looks fine, I'm using XL0 so it's easy to verify with the datasheet.

I am assuming you have xscope enabled using the config.xscope file with the line ...

Yes, I have been using that, and setting up the run configuration, and adding the -fxscope option.

It seems most likely to me that I've somehow fouled up the xn file, or there's something else that I'm missing for getting the xConnect link to work on custom hardware.

Is there an easy way to test if I've got a link set up correctly? Just getting print output doesn't seem to guarantee it's from the link... Right now I'm testing this by using the example AN00136_vendor_specific and adding printfs to the usb code (endpoint0.xc). I still may get a single print message, but the usb stops working meaning it's still a JTAG print.

[infiniteimprobability]

Is there an easy way to test if I've got a link set up correctly? Just getting print output doesn't seem to guarantee it's from the link... Right now I'm testing this by using the example AN00136_vendor_specific and adding printfs to the usb code (endpoint0.xc). I still may get a single print message, but the usb stops working meaning it's still a JTAG print.

You can normally tell from the print speed. It's instant with xscope, and can be visibly printing over JTAG. Also, you can disable the run configurations->main->target io options->xSCOPE from the GUI or remove --xscope from the xrun command. If it still prints, then it's definitely JTAG.

By the way, running with --xscope enabled will still pick up JTAG prints.

You shouldn't need the -fxscope option. As long as your config.xscope has print enabled then it does everything for you.

[ejolson9]

You shouldn't need the -fxscope option. As long as your config.xscope has print enabled then it does everything for you.

I didn't know that, interesting. I have tried removing that from the build flags, and I get this warning in the console before printing:

Code: Select all

WARNING: tile[0] - xSCOPE not supported by application, I/O will be via JTAG
WARNING: tile[1] - xSCOPE not supported by application, I/O will be via JTAG

So either that flag suppresses this warning or it's actually doing something... The first would actually make sense because I believe it is always using JTAG to print. Any ideas?

[ejolson9]

Something weird is going on... I was able to run it once without the warning. Unfortunately I cannot replicate this even though I changed nothing.

[ejolson9]

The warning stuff about

WARNING: tile[0] - xSCOPE not supported by application, I/O will be via JTAG

seems to be application dependent. With the exact same .xn file and config.xscope file the xscope printing seems to be working fine in another application (one without any usb).

This makes me think that there's something peculiar about using usb (which runs on tile 0) and printing (which I've got connected to tile 0 on my board) at the same time. Any thoughts or comments disproving this are appreciated. This was on an xcore 200 usb chip.

[infiniteimprobability]

WARNING: tile[0] - xSCOPE not supported by application, I/O will be via JTAG

This means xscope is enabled on your run configuration but not by the app. It's just there to warn you that any prints you see have been sent over the slow JTAG method, despite enabling xscope on run.
To remedy this, either disable listening for xscope prints at run, or enable xscope prints (using the config.xscope file) in your build

[ejolson9]

To remedy this, either disable listening for xscope prints at run, or enable xscope prints (using the config.xscope file) in your build

That's the thing though, I do have xscope prints enabled using the config.xscope file. And I can get printing working with the same xn file in another project, there just seems to be something bizarre with this one.

You can take a look at the pictures of my configuration in the zip if you'd like, I am building the X200 build config.

[infiniteimprobability]

Did you get this to work? Your config files all seem OK so I suspect a broken xn file as a possible cause..