Debug to stop at main and other breakpoints unresolved

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

Debug to stop at main and other breakpoints unresolved

Postby aclassifier » Mon Nov 14, 2016 10:23 pm

I run my code on a startKIT.

A. If I set a breakpoint on main() in file main.xc it says "Unresolved breakpoint" there when it runs, but the file shows up fine. Also, the code starts and runs and prints to the console etc.

B. If I do "Run : Debug Configurations : Stop on startup at: main" then it says "No source available for "main() ".

C. It actually says "Unresolved breakpoint" on any line I try to stop it on...

I don't know when this happened, as I have been away from the coding for a while. I then used 14.1.0 but now Community_14.2.3. I used to have main in the project file _Aquarium.xc but then I moved it into the new main.xc. Before this I called it Aquarium.xe, and I have tried to make new and tried to import and to drag and drop. But the descriptions A, B, C above go for all.

Debugging without breakpoints I can't. It seems to behave like it only "runs"(?)

I think I have ok config.xscope and STARTKIT.xn, but I have no xscope.xmt.

I have JRE 1.8.0_101 and OS X 10.11.6

My makefile:

TARGET = STARTKIT
APP_NAME = _Aquarium
USED_MODULES = lib_startkit_support module_i2c_master module_random
XCC_FLAGS = -O2 -g -report -fxscope -save-temps
XCORE_ARM_PROJECT = 0
VERBOSE = 0
XMOS_MAKE_PATH ?= ../..
-include $(XMOS_MAKE_PATH)/xcommon/module_xcommon/build/Makefile.common
ENABLE_STAGED_BUILD=0

Build log:
21:45:42 **** Build of configuration Default for project _Aquarium ****
xmake CONFIG=Default all
Checking build modules
Using build modules: lib_startkit_support(2.0.0) module_i2c_master module_random
Creating dependencies for globl_bug_fix.S
Creating dependencies for random.xc
Creating dependencies for i2c-mm.xc
Creating dependencies for startkit_slider.xc
Creating dependencies for startkit_gpio.xc
Creating dependencies for startkit_adc.xc
Creating dependencies for slider.xc
Creating dependencies for capsens.xc
Creating dependencies for module_cancelable_delay.xc
Creating dependencies for main.xc
Creating dependencies for lib_startKIT_adc_client.xc
Creating dependencies for i2c_internal.xc
Creating dependencies for i2c_external.xc
Creating dependencies for button_press.xc
Creating dependencies for adafruit_display_ssd1306_128x32_i2c.xc
Creating dependencies for _Aquarium.xc
Creating dependencies for random_init.c
Creating dependencies for core_graphics_adafruit_GFX.c
Compiling core_graphics_adafruit_GFX.c
Compiling random_init.c
Compiling _Aquarium.xc
Compiling adafruit_display_ssd1306_128x32_i2c.xc
Compiling button_press.xc
Compiling i2c_external.xc
Compiling i2c_internal.xc
Compiling lib_startKIT_adc_client.xc
Compiling main.xc
Compiling module_cancelable_delay.xc
Compiling capsens.xc
Compiling slider.xc
Compiling startkit_adc.xc
Compiling startkit_gpio.xc
Compiling startkit_slider.xc
Compiling i2c-mm.xc
Compiling random.xc
Compiling globl_bug_fix.S
Creating _Aquarium.xe
Constraint check for tile[0]:
Cores available: 8, used: 4 . OKAY
Timers available: 10, used: 5 . OKAY
Chanends available: 32, used: 15 . OKAY
Memory available: 65536, used: 34664 . OKAY
(Stack: 5612, Code: 24846, Data: 4206)
Constraints checks PASSED.
Build Complete

21:45:49 Build Finished (took 6s.684ms)
peter
XCore Addict
Posts: 230
Joined: Wed Mar 10, 2010 12:46 pm

Postby peter » Tue Nov 15, 2016 10:44 am

Hi aclassifier,

Is there any chance you could provide your binary for us to look at what the tools are producing?

Regards,

Peter
User avatar
aclassifier
Respected Member
Posts: 319
Joined: Wed Apr 25, 2012 8:52 pm
Contact:

Postby aclassifier » Tue Nov 15, 2016 10:44 am

peter wrote:Hi aclassifier,

Is there any chance you could provide your binary for us to look at what the tools are producing?

Regards,

Peter


Of course. Just mail me and I'll mail a zip for you. But it's so unfinished that I don't want to make it public yet - http://www.teigfam.net/oyvind/me/email.html
DemoniacMilk
XCore Addict
Posts: 191
Joined: Tue Jul 05, 2016 2:19 pm

Postby DemoniacMilk » Tue Nov 15, 2016 5:20 pm

If you want to use breakpoints just for checking the content of some variables or a small chunk of memory, then you might use xscope prints and offline xscope, especially as a lof of values might be optimized out on high optimization levels when hitting a breakpoint.

Primarily you need to add -fxscope to you build options, include xscope.h and print.h (print.h for more optimized print functions) and add a config.xscope file to your project folder containing

Code: Select all

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


All info you need can be found in AN10089_xscope_printing (use printf via xscope) and AN00195_Getting_started_with_offline_xSCOPE_in_xTIMEcomposer_Studio (graphical output on a tool-internal scope) accessible in the examples section.
User avatar
aclassifier
Respected Member
Posts: 319
Joined: Wed Apr 25, 2012 8:52 pm
Contact:

Postby aclassifier » Tue Nov 15, 2016 5:20 pm

Thanks, but printf works fine. I have described it at http://www.teigfam.net/oyvind/home/tech ... n_startkit, because I always seem to fiddle with it. But it looks like I should update with these points as well.

DemoniacMilk wrote:If you want to use breakpoints just for checking the content of some variables or a small chunk of memory, then you might use xscope prints and offline xscope, especially as a lof of values might be optimized out on high optimization levels when hitting a breakpoint.

Primarily you need to add -fxscope to you build options, include xscope.h and print.h (print.h for more optimized print functions) and add a config.xscope file to your project folder containing

Code: Select all

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


All info you need can be found in AN10089_xscope_printing (use printf via xscope) and AN00195_Getting_started_with_offline_xSCOPE_in_xTIMEcomposer_Studio (graphical output on a tool-internal scope) accessible in the examples section.
User avatar
aclassifier
Respected Member
Posts: 319
Joined: Wed Apr 25, 2012 8:52 pm
Contact:

Postby aclassifier » Tue Nov 15, 2016 9:04 pm

I had started the debugging from the top project file structure entry. Instead I tried to start it from the bin fold at _Aquarium.xe. Then the breakpoint comes up and it stops like it should. As it now also does if I do it from the top..

However, stopping in main() still is unresolved, and so is the file where main is (main.xc). But it knows the assembly and stops there.

The unresolved breakpoints elsewhere may have been because of some optimised away code(?), because I am able to find valid breakpoints in the same file, at other lines.

I don't feel like I hold the steering wheel.

I am aware of https://www.xmos.com/download/private/AN00193%3A-Getting-Started-with-Debugging-in-xTIMEcomposer-Studio%281.0.1rc1%29.pdf
phasemage
Junior Member
Posts: 6
Joined: Wed Dec 28, 2016 2:32 am

Postby phasemage » Wed Dec 28, 2016 2:38 am

I'm hitting this same problem with all the examples.

No source available for "main() "

Breakpoints in source don't hit.
henk
Respected Member
Posts: 346
Joined: Wed Jan 27, 2016 5:21 pm

Postby henk » Wed Dec 28, 2016 8:30 am

Is this a multi-core main? Ie, one that just has

Code: Select all

int main() {
  par {
    on tile[0]: { X(); }
    on tile[0]: { Y(); }
  }
  return 0;
}


If so - that won't have any source code associated with it (try and put a line before or after the par and the compiler will complain), and hence you probably won't be able to put a breakpoint in it. The first line that you can put a breakpoint in is the function X() or Y().
User avatar
aclassifier
Respected Member
Posts: 319
Joined: Wed Apr 25, 2012 8:52 pm
Contact:

Postby aclassifier » Wed Dec 28, 2016 8:30 am

henk wrote:Is this a multi-core main? Ie, one that just has

Code: Select all

int main() {
  par {
    on tile[0]: { X(); }
    on tile[0]: { Y(); }
  }
  return 0;
}


If so - that won't have any source code associated with it (try and put a line before or after the par and the compiler will complain), and hence you probably won't be able to put a breakpoint in it. The first line that you can put a breakpoint in is the function X() or Y().


Yes, it is a multi-core main. Thanks, I see your point, Henk! But then, the IDE perhaps shouldn't have allowed me to put a breakpoint there? Is this an Eclipse matter?
henk
Respected Member
Posts: 346
Joined: Wed Jan 27, 2016 5:21 pm

Postby henk » Wed Dec 28, 2016 5:03 pm

Yes you are right - that is a bug in the user interface.

I am not sure whether it is easily fixable - raise it as a tools bug?

Cheers,
Henk

Who is online

Users browsing this forum: No registered users and 137 guests