XTAG-3 debug log hanging?

[CousinItt]

I've just used the latest available from within xTC, which is 2.1.0. I haven't checked the latest-and-greatest on GitHub.

[aclassifier]

I think I finally got it in. But I guess my recipe is rather hopeless(?) or close to:

1. I had an older version of lib_logging already included. I can't remember how I stumbled it into success..
2. I copied the old lib_logging out of /workspace and kept the original. This was supposed to be my backup
3. I used github desktop and cloned from https://github.com/xmos/lib_logging
4. (If I tried to download the zip what came out was a directory called lib_logging-develop, so I decided not to use it)
5. I went to the place on the disk where it was stored
6. I quit xTIMEcomposer
7. I pasted the new on top of the old and replied 'yes' on making a new lib_logging
8. When I started xTIMEcomposer lib_logging looked unfinished. xTIMEcomposer said it missed ".project". Thanx
9. I quite xTIMEcomposer
10. I copied .project from the backup to /workspace/lib_logging. (On macOS I have dot-files visible)
11. I started xTIMEcomposer again and now lib_logging was seen
12. But in the top view it said lib_logging [lib_logging develop]. Even if I had just cloned from the https://github.com/xmos/lib_logging
13. But module_build_info says VERSION = 3.0.2 fair enough. But is this the one I want?
14. In my project it was shown as lib_logging/lib_logging since there is a /lib_logging below the top /lib_logging. Puh!
15. I crossed my fingers and used the Explorer window in xTIMEcomposer and boldly moved all contents of /lib_logging/lib_logging up into /lib_logging, then deleted the old /lib_logging/lib_logging. Now..?
16. Bingo! Now, when I open my project makefile the library list comes up as /lib_logging
17. But in xTIMEcomposer Library window lib_logging 2.10 is still shown. Why? Because 3.02 snuck in? How do I update it?

[CousinItt]

You seem to be making a meal of this. You can either start with a fresh workspace or remove /lib_logging from your existing workspace by deleting it from the project explorer. Take a copy first if you want. Then just find lib_logging in the libraries pane, right-click or double-click on it and import it into the workspace. Let xTC do the work.

[aclassifier]

But right clicking doesn't work. I must look at how it's set up. At some time, several years ago, it stopped working.

My xTIMEcomposer doesn't see the XMOS server, I get an error message down in the right corner from time to time.

But now I know that this would all do the trick, I'll try for the connection.

[CousinItt]

Maybe you need a fresh installation.

[aclassifier]

Maybe you need a fresh installation.

This did not help for my xTIMEcomposer getting in contact with the XMOS servers. I will come back to this. But first, the lib_logging.

The scheme I showed in an earlier post did not succed when I wanted to use the newest version. But I had 2.1.0 in the Libraries pan, so I deleted the not successful and installed 2.1.0 again.

The makefile saw "lib_logging" and I did tick it on and added this:

XCC_MAP_FLAGS += -DDEBUG_PRINT_ENABLE=1

But

#include "debug_print.h" or
#include <debug_print.h>

did not succeed before I added

XCC_FLAGS += -I/Users/teig/workspace/lib_logging/api

But now it's taken fine and compiles. Why?

If I introduce an error in lib_logging debug_printf.c it's caught, so lib_logging is seen.

Thew config xscope initial line is now:

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

But I get no printing! And no complaints from XScope.

I have read in the xTIMEcomposer User Guide for tools version 14.0.x (412) pages but I am not able to find the right place to find out about this.

There is some talk about #define DEBUG_UNIT but how do I find out what my debug unit is? And, is this necessary when I have DEBUG_PRINT_ENABLE=1?

[aclassifier]

I have now made a local file debug_conf.h and added
#define DEBUG_PRINT_ENABLE_XC_TEST_TOROID_1_232_XC_ and I see that it's included by lib_logging/api/debug_print.h ok.

But then, just having XCC_MAP_FLAGS += -DDEBUG_PRINT_ENABLE=1 should have done it.

Update: I did this and now I see logs. In lib_logging/api/debug_print.h[/font:

Code: Select all

#if DEBUG_PRINT_ENABLE0
#define debug_printf(...) debug_printf(__VA_ARGS__)
#else
#warning Why no debug_printf..?, forcing it:
// #define debug_printf(...)
#define debug_printf(...) debug_printf(__VA_ARGS__)
#endif

I guess this is my problem from now, if those new-won debug_printf work better than my printf. If not..

[CousinItt]

DEBUG_UNIT is a way to selectively get output from only one file, so you don't have to rip out print statements from the other files in a project. This is explained in the debug_printing_library document supplied with lib_logging. Alternatively you can print from any file using the general DEBUG_PRINT_ENABLE=1.

Have you tried just downloading the logging example? Also, don't forget this will only work when running or debugging, not with flashed code.

[aclassifier]

Thanks, CousinItt, looks like I got it all up and running now, and what's better, it looks like lib_logging is reliable, as opposed to the JTAG-printing (which has been reliable enough for me up to this stress-test, true to say).

The fact that it doensn't support float is easily solved by building the string with sprintf, like this:

Code: Select all

int  len;
char chars_str [SPRINTF_LEN];

len = sprintf (chars_str, "C:(%u %u) %.2f to %.2f with ", context.iof_row, context.iof_col, old_temp, context.temp);
for (unsigned index = 0; index < NUM_CONNS_PER_NODE; index++){
    len += sprintf (len+chars_str, "[S:(%03u,%03u) %.2f] ", context.server_pos[index].iof_row, context.server_pos[index].iof_col, context.intemps[index]);
}
len += sprintf (len+chars_str, "%s", "\n");

debug_printf ("%s", chars_str);