XTAG-3 debug log hanging?

Technical questions regarding the xTIMEcomposer, xSOFTip Explorer and Programming with XMOS.
User avatar
Respected Member
Posts: 336
Joined: Wed Apr 25, 2012 8:52 pm

XTAG-3 debug log hanging?

Postby aclassifier » Wed Sep 19, 2018 12:41 pm

Is there any chance that logging to XTAG-3 may hang? (Update: The xTC is fine after this, but seems to have lost connection with my target)

If so, is there a chance that this will then freeze the rest of my code? This depends on how it's connected I guess, if the I/O server may block on interface of channel calls.

I will blink a LED just to see of there is activity when it seems to stop. Of course I also need to scope activity to dig further. However, I would have liked to hear other user's experience with logging also.

Will the XTAG-3 LEDs still blink if the XC code runs if the USB SW on my machine is not responding? xTIMEcomposer does not display my log any more, but apart from that all seems fine with xTC.

The XTAG-3 is connected to an xCore-200 eXplorerKIT (1702-000101).

If it may hang, what could I possible try to make it not hang? Shorter cable? Some driver issue (below)?

The whole thing detects 433 MHz lowest signal level from a startKIT with an RFM69 radio every 10 seconds. The debug log (about 500 chars) is done between the receptions.

I also have an SPI comm on the eXplorerKIT (that does not run very fast) that might hang, but it is very well surveilled. I use lib_spi 3.0.2.

When things stop (after hours or days) it's always hard to find the cause.


XTAG-3 is (full data below, Norwegian headings I'm afraid) connected via a 1m USB cable to OS X 10.11.6 (El Capitan) with xTC Community_14.3.3 (build 22296, Apr-19-2018) and running JTAG I/O server. JRE is 1.8.0_144. I know that 1.8.1 181 build 13 is available. However, I have kept this old'ish version because xTC 14.3.3 will not do flashing etc. with newer versions. (See [1])


Produkt-ID: 0xf7d4
Leverandør-ID: 0x20b1
Versjon: 10.06
Serienummer: XD00t_8JmqnHNZCF
Hastighet: Opptil 480 Mb/sek.
Produsent: XMOS
Sted-ID: 0x14200000 / 9
Tilgjengelig strøm (mA): 1000
Strømkrav (mA): 500
Ekstra driftsstrøm (mA): 0

[1] xTIMEcomposer and not(?) macOS High Sierra
User avatar
Respected Member
Posts: 336
Joined: Wed Apr 25, 2012 8:52 pm

Postby aclassifier » Mon Sep 24, 2018 3:18 pm

I have researched more on this. I just list up some new assumptions here. They may need corrections:
  1. Yes, a printf blocks the core that calls it, even if all works and xTIMEcomposer picks up the messages fine.
  2. This may mean that if I printf from more than one core it would block the actual one that's multiplexed at the time
  3. I saw this because I made a task that blinked with the built-in LEDs on the eXplorerKIT. When the log was going on the blinking was disturbed. It went on or off at odd times. I had tried to set some LEDs before and after printf
  4. When I moved the blinking task to another core the blinking pattern was just like it should be
  5. Could anybody tell how the XTAG-3 holds an XCORE task? On the XC side, in the library, may this be done in XC or must there be some asm to do it?
  6. It seems like this blocking instruction only blocks the calling core?
  7. I made a watchdog type timeout in the blinking task that runs on another core. If a one-sec timeout in the printing task or the other blinking calls are not run within 3 seconds it starts to blink real fast. However, if I unplug the USB from the XTAG-3 my watchdog task does not get timed out. It seems like even that core is not scheduled and running. At this time, all LEDs on XTAG-3 are off, since the board is not powered. Now am I bewildered?
User avatar
XCore Legend
Posts: 1675
Joined: Thu Jun 10, 2010 11:43 am

Postby mon2 » Tue Sep 25, 2018 2:12 am

Printf is blocking but there is a workaround to make it realtime:

http://www.xmos.com/de/support/tools/do ... ion=X1093A
User avatar
Respected Member
Posts: 336
Joined: Wed Apr 25, 2012 8:52 pm

Postby aclassifier » Tue Sep 25, 2018 10:18 am

Great! Thanks a lot, mon2!

From the text there I infer that the whole slice is blocking, and that this is an effect of debug handling, where a breakpoint would wont this to happen?

Also, my starting question was whether anybody had seen problems with the USB drivers or xTIMEcomposer SW so that printf fails, and by that blocks the XCORE? The XMOS boards come with a very short USB cable, I have used a longer one (1m)..

Who is online

Users browsing this forum: No registered users and 1 guest