XTAG-3 debug log hanging?

Technical questions regarding the XTC tools and programming with XMOS.
User avatar
aclassifier
Respected Member
Posts: 483
Joined: Wed Apr 25, 2012 8:52 pm
Contact:

XTAG-3 debug log hanging?

Post by aclassifier »

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])

XMOS XTAG-3:

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


--
Øyvind Teig
Trondheim (Norway)
https://www.teigfam.net/oyvind/home/
User avatar
aclassifier
Respected Member
Posts: 483
Joined: Wed Apr 25, 2012 8:52 pm
Contact:

Post by aclassifier »

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?
--
Øyvind Teig
Trondheim (Norway)
https://www.teigfam.net/oyvind/home/
User avatar
mon2
XCore Legend
Posts: 1913
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Post by mon2 »

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

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

Post by aclassifier »

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)..
--
Øyvind Teig
Trondheim (Norway)
https://www.teigfam.net/oyvind/home/
User avatar
aclassifier
Respected Member
Posts: 483
Joined: Wed Apr 25, 2012 8:52 pm
Contact:

Post by aclassifier »

I see that the http://www.xmos.com/de/support/tools/.../X1093A url points to a document with some graphics not shown.

The full document is at https://www.xmos.ai/download/Debug-with-printf-in-real-time(X1093A).pdf. Also available from "Donwload PDF" of the top url! (I didn't observe that at first..)
--
Øyvind Teig
Trondheim (Norway)
https://www.teigfam.net/oyvind/home/
User avatar
aclassifier
Respected Member
Posts: 483
Joined: Wed Apr 25, 2012 8:52 pm
Contact:

Post by aclassifier »

If anybody could help me with the XA1039A app note I'd be happy. I have done the following. Any corrections, minor or major would be fine.

I have no idea how the app note's code may ever compile. I get error: port `receive' is uninitialized etc. and even if I initialise those ports to something I get:

Code: Select all

../src/redirect_print.xc: Error: Undefined reference to 'process'
../src/redirect_print.xc: Warning: Undefined reference to 'xscope_config_io'
../src/redirect_print.xc: Warning: Undefined reference to 'xscope_register'
I guessed I need to fill something into config.xscope like, but this must be wrong since I got the errors above:

Code: Select all

<Probe name="receive" type="CONTINUOUS" datatype="UINT" units="Value" enabled="true"/>
<Probe name="transmit" type="CONTINUOUS" datatype="UINT" units="Value" enabled="true"/>
Since I am going to try this redirect in SW i already have, I made a files called redirect_print.h and redirect_print.xc. Here is the latter:

Code: Select all

#include <xs1.h>
#include <platform.h> // slice
#include <stdio.h>
#include <xscope.h>
//#include <xccompat.h>

#include "redirect_print.h"

// XS1_PORT_1G etc just to keep the compiler quiet. 
// But on the eXplorerKIT
// X0D41 A0-in  8D5 16B13 DN0 uplink ??
// X0D42 A0-out 8D6 16B14 UP0 uplink ??
//
in  buffered port:1 receive  = on tile[0]: XS1_PORT_1G; 
out buffered port:1 transmit = on tile[0]: XS1_PORT_1H;
// port receive;
// port transmit;

int process(int);

void xscope_user_init (void) {
    xscope_register(0);
    xscope_config_io(XSCOPE_IO_BASIC);
}

void redirect_print() {
    while (1) {
        int dataIn, dataOut;
        receive :> dataIn;
        dataOut = process(dataIn);
        /* Debug Information */
        if (dataOut < 0) {
            printf("%d %d", dataIn, dataOut);
        } else {}
        transmit <: dataOut;
    }
}
I am far from there! I have now just started redirect_print as a component in my main's par.

But then I need to print out from both tiles. If this will ever work, will it work for both?

Or.. since the 2013 document, is there some trick in the xTIMEcomposer to just tick something off and get it done? I checked the release notes from then and didn't find anything.

The reason I am testing all this out is that I have a serious printout problem, probably coming from printing out too fast. But then, printing should be blocking? I have reported this as a ticket to XMOS. I had a hoped the XTAG-3 printing may help..
--
Øyvind Teig
Trondheim (Norway)
https://www.teigfam.net/oyvind/home/
User avatar
CousinItt
Respected Member
Posts: 360
Joined: Wed May 31, 2017 6:55 pm

Post by CousinItt »

This all seems a bit of a palaver. Have you tried lib_logging with xscope? I've found it to be very reliable, and it will let me debug_print() from any tile in a network.
User avatar
aclassifier
Respected Member
Posts: 483
Joined: Wed Apr 25, 2012 8:52 pm
Contact:

Post by aclassifier »

Thanks for a response, @CousinItt!

No I haven't tried lib_logging, but I see that I have mentioned it in a blog note [1] and have it installed.

Great! Is there anything clever I need to know? Some quick-tip to get up and going?

[1] https://www.teigfam.net/oyvind/home/tec ... otes-wifi/
--
Øyvind Teig
Trondheim (Norway)
https://www.teigfam.net/oyvind/home/
User avatar
CousinItt
Respected Member
Posts: 360
Joined: Wed May 31, 2017 6:55 pm

Post by CousinItt »

Just try the AN00239 example.

config.xscope has the line <xSCOPEconfig ioMode="basic" enabled="true">

The makefile includes the library, and the additional XCC flag -DDEBUG_PRINT_ENABLE=1 for general printing, or, for example -DDEBUG_PRINT_ENABLE_unit to print from a single module. A matching definition has to go in the module concerned.

It's very straightforward and all in the app note. Of course it only works when running or debugging with xscope enabled.
User avatar
aclassifier
Respected Member
Posts: 483
Joined: Wed Apr 25, 2012 8:52 pm
Contact:

Post by aclassifier »

Ok. Is it the
lib_logging (I have VERSION = 2.1.0) or the
lib_logging_develop (from https://github.com/xmos/lib_logging on github: VERSION = 3.0.2)
?

I see that develop is the current/default branch. I wish it could have appeared in the xTIMEcomposer Library tab.. I struggle with these libraries.
Last edited by aclassifier on Sun Jan 24, 2021 8:27 pm, edited 1 time in total.
--
Øyvind Teig
Trondheim (Norway)
https://www.teigfam.net/oyvind/home/
Post Reply