Page 1 of 2

Debug to stop at main and other breakpoints unresolved

Posted: Mon Nov 14, 2016 10:23 pm
by aclassifier
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)

Re: Debug to stop at main and other breakpoints unresolved

Posted: Tue Nov 15, 2016 10:44 am
by peter
Hi aclassifier,

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

Regards,

Peter

Re: Debug to stop at main and other breakpoints unresolved

Posted: Tue Nov 15, 2016 10:44 am
by aclassifier
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

Re: Debug to stop at main and other breakpoints unresolved

Posted: Tue Nov 15, 2016 5:20 pm
by DemoniacMilk
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.

Re: Debug to stop at main and other breakpoints unresolved

Posted: Tue Nov 15, 2016 5:20 pm
by aclassifier
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.

Re: Debug to stop at main and other breakpoints unresolved

Posted: Tue Nov 15, 2016 9:04 pm
by aclassifier
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

Re: Debug to stop at main and other breakpoints unresolved

Posted: Wed Dec 28, 2016 2:38 am
by phasemage
I'm hitting this same problem with all the examples.

No source available for "main() "

Breakpoints in source don't hit.

Re: Debug to stop at main and other breakpoints unresolved

Posted: Wed Dec 28, 2016 8:30 am
by henk
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().

Re: Debug to stop at main and other breakpoints unresolved

Posted: Wed Dec 28, 2016 8:30 am
by aclassifier
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?

Re: Debug to stop at main and other breakpoints unresolved

Posted: Wed Dec 28, 2016 5:03 pm
by henk
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