Dual core debugging problem

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Dual core debugging problem

1,650 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by wlamers on Mon Jul 14 03:49:12 MST 2014
Hardware/software:
- LPC4357
- LPCXpresso 7.2.0
- LPCopen 2.12
- Using multi-core templates from LPCXpresso
- Red Probe+ (and LPC-Link 2)

Debugger settings M0 core
- Vector catch: false
- Debug Protocol: JTAG
- Attach only
- Use full file path to set breakpoints: enabled

Problem description
The program consists of code for both the M4 and M0 core. Firmware is flashed by staring a debug session of the M4 core. Then if I want to debug the M0 core code I start a debug session of the M0 core (attach only). If I set a breakpoint it will be hit properly. But if I then want to step through the code or continue running the code I get the following error (every time):

15: Target error from Set break/watch
Unable to set an execution break - no resource available.

Stepping through code or continuing running works if I set 'skip all breakpoints' of if no breakpoints are set at all.
Strange thing of this problem is that the debugger perfectly catches breakpoints when set and the IDE also shows the corresponding line. Everything else works perfectly. Debugging the M4 core is also no problem at all. I got these errors also with earlier versions of LPCXpresso and other boards. This leads to my conclusion that it is simply some sort of setting. But I am out of options after several months of trying and working around of this. I hope someone can help.


0 Kudos
Reply
7 Replies

1,571 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by lpcxpresso-support on Tue Jul 15 01:00:20 MST 2014
Basically, no. If you start the M0 debug session before the M4 releases it from reset, you WILL hit the initial (temporary) breakpoint. This can be very important for debugging 'early' code...
0 Kudos
Reply

1,571 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by wlamers on Tue Jul 15 00:45:34 MST 2014
Thanks for that! Stepping works now. I guess I will be limited to just one (active) breakpoint then for the M0 core when using stepping.

The fact that the temporary breakpoint is still active (in the above example) is probably caused by the fact that the M4 releases the M0 and debugging is started much later (manually). Hence the first temporary breakpoint is never hit. If this is actually correct, would it not be better to deactivate the temporary breakpoint by default (M0 only of course)?
0 Kudos
Reply

1,571 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by lpcxpresso-support on Tue Jul 15 00:35:00 MST 2014
This is happening because you DO have 2 breakpoints set, and any sort of "step" will cause more breakpoints to be used.

The two breakpoints that you have set are:
- the (temporary) breakpoint on main() - this does not show in the breakpoint list
- the breakpoint on your function

You can stop the breakpoint on main being set by reading this FAQ
http://www.lpcware.com/content/faq/lpcxpresso/changing-initial-breakpoint
and unchecking "Stop on startup at:"

Note: A temporary breakpoint is one that is automatically removed the first time it is hit.
0 Kudos
Reply

1,571 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by wlamers on Mon Jul 14 08:11:53 MST 2014
I tried deselecting "Alternate fix for debugger path" with no luck I'm afraid.

The Breakpoints view has only one breakpoint:
DAQ_MasterFunc_M0.c [line: 497]


This is the GDB traces view. I removed the line breaks for easier reading and added some comments.


START OF THE GDB TRACE:


473,816 2-environment-cd D:/FIRMWARE_2014/VMS20_MasterApp_M0
473,824 2^done
473,824 (gdb) 
473,824 3-gdb-set breakpoint pending on
473,834 3^done
473,834 (gdb) 
473,834 4-enable-pretty-printing
473,844 4^done
473,844 (gdb) 
473,844 5maintenance set python print-stack off
473,854 &"maintenance set python print-stack off\n"
473,854 &"Undefined maintenance set command: \"python print-stack off\".  Try \"help maintenance set\".\n"
473,854 5^error,msg="Undefined maintenance set command: \"python print-stack off\".  Try \"help maintenance set\"."
473,854 (gdb) 
473,854 6-gdb-set print object on
473,864 6^done
473,864 (gdb) 
473,864 7-gdb-set print sevenbit-strings on
473,874 7^done
473,874 (gdb) 
473,874 8-gdb-set charset ISO-8859-1
473,884 8^done
473,884 (gdb) 
473,884 9-gdb-set auto-solib-add on
473,894 9^done
473,894 (gdb) 
473,900 10-file-exec-and-symbols --thread-group i1 D:/FIRMWARE_2014/DAQ_MasterApp_M0/Debug/DAQ_MasterApp_M0.axf
473,907 10^done
473,907 (gdb) 
473,911 11set remotetimeout 60000
473,917 &"set remotetimeout 60000\n"
473,917 =cmd-param-changed,param="remotetimeout",value="60000"
473,917 11^done
473,917 (gdb) 
473,959 12-target-select extended-remote | crt_emu_lpc18_43_nxp -msg-port=52035 -g -mi -2 -pLPC4357-M0 -vendor=NXP -attach -e0 -wire=jtag -scan D:\\FIRMWARE_2014\\DAQ_MasterApp_M0\\Debug\\DAQ_MasterApp_M0_Debug.jtag -flash-driver=LPC18x7_43x7_2x512_BootA.cfx -x D:/FIRMWARE_2014/DAQ_MasterApp_M0/Debug
474,539 =thread-group-started,id="i1",pid="42000"
474,540 =thread-created,id="1",group-id="i1"
474,540 13-list-thread-groups --available
474,551 *stopped,frame={addr="0x00000000",func="??",args=[]},thread-id="1",stopped-threads="all"
474,552 12^connected
474,552 (gdb) 
474,552 13^error,msg="Can not fetch data now."
474,552 (gdb) 
474,553 14set mem inaccessible-by-default off
474,562 &"set mem inaccessible-by-default off\n"
474,562 =cmd-param-changed,param="mem inaccessible-by-default",value="off"
474,562 14^done
474,562 (gdb) 
474,562 15mon ondisconnect cont
474,572 &"mon ondisconnect cont\n"
474,582 15^done
474,582 (gdb) 
474,582 16set arm force-mode thumb
474,592 &"set arm force-mode thumb\n"
474,592 =cmd-param-changed,param="arm force-mode",value="thumb"
474,592 16^done
474,592 (gdb) 
474,592 17-target-download
474,622 17+download,{section=".text",section-size="49456",total-size="33818809"}
474,622 17+download,{section=".text",section-sent="15952",section-size="49456",total-sent="15952",total-size="33818809"}
474,642 17+download,{section=".data",section-size="8",total-size="33818809"}
474,663 17^done,address="0x1b001e34",load-size="49464",transfer-rate="7914240",write-rate="9892"
474,663 (gdb) 
474,663 18-interpreter-exec console "mon capabilities"
474,683 18^done
474,683 (gdb) 
474,683 19-interpreter-exec console "mon semihost enable"
474,703 19^done
474,703 (gdb) 
474,703 20-interpreter-exec console "mon info,all"
474,723 20^done
474,723 (gdb) 
475,024 21-data-list-register-names
475,024 22-list-thread-groups
475,033 21^done,register-names=["r0","r1","r2","r3","r4","r5","r6","r7","r8","r9","r10","r11","r12","sp","lr","pc","","","","","","","","","","xpsr","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","cycles"]
475,033 (gdb) 
475,036 23-gdb-show --thread-group i1 language
475,043 22^done,groups=[{id="i1",type="process",pid="42000",executable="D:\\FIRMWARE_2014\\DAQ_MasterApp_M0\\Debug\\DAQ_MasterApp_M0.axf"}]
475,043 (gdb) 
475,043 23^done,value="auto"
475,043 (gdb) 
475,043 24-gdb-set --thread-group i1 language c
475,053 24^done
475,053 (gdb) 
475,053 25-data-evaluate-expression --thread-group i1 "sizeof (void*)"
475,064 25^done,value="4"
475,064 (gdb) 
475,064 26-gdb-set --thread-group i1 language auto
475,074 26^done
475,074 (gdb) 
475,074 27-interpreter-exec --thread-group i1 console "show endian"
475,083 28-list-thread-groups i1
475,084 ~"The target endianness is set automatically (currently little endian)\n"
475,084 27^done
475,084 (gdb) 
475,087 29-break-insert --thread-group i1 -f D:/FIRMWARE_2014/DAQ_MasterApp_M0/src/DAQ_MasterFunc_M0.c:497
475,104 28^done,threads=[{id="1",target-id="Thread <main>",frame={level="0",addr="0x1b001e34",func="ResetISR",args=[],file="../src/cr_startup_lpc43xx-m0app.c",fullname="D:\\FIRMWARE_2014\\DAQ_MasterApp_M0\\src\\cr_startup_lpc43xx-m0app.c",line="333"},state="stopped"}]
475,104 (gdb) 
475,115 30-stack-info-depth --thread 1 11
475,138 29^done,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x1b0011ee",func="eMMC_diskInfo",file="../src/DAQ_MasterFunc_M0.c",fullname="D:\\FIRMWARE_2014\\DAQ_MasterApp_M0\\src\\DAQ_MasterFunc_M0.c",line="497",thread-groups=["i1"],times="0",original-location="D:/FIRMWARE_2014/DAQ_MasterApp_M0/src/DAQ_MasterFunc_M0.c:497"}
475,139 (gdb) 
475,139 30^done,depth="1"
475,139 (gdb) 
475,142 31-break-insert --thread-group i1 -t -f main
475,162 32-stack-list-frames --thread 1
475,182 31^done,bkpt={number="2",type="breakpoint",disp="del",enabled="y",addr="0x1b0001f6",func="main",file="../src/DAQ_MasterApp_M0.c",fullname="D:\\FIRMWARE_2014\\DAQ_MasterApp_M0\\src\\DAQ_MasterApp_M0.c",line="8",thread-groups=["i1"],times="0",original-location="main"}
475,182 (gdb) 
475,182 32^done,stack=[frame={level="0",addr="0x1b001e34",func="ResetISR",file="../src/cr_startup_lpc43xx-m0app.c",fullname="D:\\FIRMWARE_2014\\DAQ_MasterApp_M0\\src\\cr_startup_lpc43xx-m0app.c",line="333"}]
475,182 (gdb) 
475,185 33-exec-continue --thread-group i1
475,192 ~"Note: automatically using hardware breakpoints for read-only addresses.\n"
475,222 33^running
475,222 *running,thread-id="all"
475,222 (gdb)



AND HERE COMES THE BREAKPOINT HIT:



672,935 =breakpoint-modified,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x1b0011ee",func="eMMC_diskInfo",file="../src/DAQ_MasterFunc_M0.c",fullname="D:\\\\FIRMWARE_2014\\\\DAQ_MasterApp_M0\\\\src\\\\DAQ_MasterFunc_M0.c",line="497",thread-groups=["i1"],times="1",original-location="D:/FIRMWARE_2014/DAQ_MasterApp_M0/src/DAQ_MasterFunc_M0.c:497"}
672,975 *stopped,reason="breakpoint-hit",disp="keep",bkptno="1",frame={addr="0x1b0011ee",func="eMMC_diskInfo",args=[],file="../src/DAQ_MasterFunc_M0.c",fullname="D:\\FIRMWARE_2014\\DAQ_MasterApp_M0\\src\\DAQ_MasterFunc_M0.c",line="497"},thread-id="1",stopped-threads="all"
672,975 (gdb) 
673,046 34-stack-info-depth --thread 1 11
673,065 34^done,depth="2"
673,065 (gdb) 
673,084 35-stack-list-frames --thread 1 1 1
673,084 36-thread-info 1
673,084 37-list-thread-groups
673,085 35^done,stack=[frame={level="1",addr="0x1b0002b2",func="main",file="../src/DAQ_MasterApp_M0.c",fullname="D:\\FIRMWARE_2014\\DAQ_MasterApp_M0\\src\\DAQ_MasterApp_M0.c",line="39"}]
673,085 (gdb) 
673,095 36^done,threads=[{id="1",target-id="Thread <main>",frame={level="0",addr="0x1b0011ee",func="eMMC_diskInfo",args=[],file="../src/DAQ_MasterFunc_M0.c",fullname="D:\\FIRMWARE_2014\\DAQ_MasterApp_M0\\src\\DAQ_MasterFunc_M0.c",line="497"},state="stopped"}]
673,095 (gdb) 
673,095 37^done,groups=[{id="i1",type="process",pid="42000",executable="D:\\FIRMWARE_2014\\DAQ_MasterApp_M0\\Debug\\DAQ_MasterApp_M0.axf"}]
673,095 (gdb) 
673,282 38-stack-list-frames --thread 1
673,285 38^done,stack=[frame={level="0",addr="0x1b0011ee",func="eMMC_diskInfo",file="../src/DAQ_MasterFunc_M0.c",fullname="D:\\FIRMWARE_2014\\DAQ_MasterApp_M0\\src\\DAQ_MasterFunc_M0.c",line="497"},frame={level="1",addr="0x1b0002b2",func="main",file="../src/DAQ_MasterApp_M0.c",fullname="D:\\FIRMWARE_2014\\DAQ_MasterApp_M0\\src\\DAQ_MasterApp_M0.c",line="39"}]
673,285 (gdb) 
673,347 39-stack-list-frames --thread 1 0 1
673,355 39^done,stack=[frame={level="0",addr="0x1b0011ee",func="eMMC_diskInfo",file="../src/DAQ_MasterFunc_M0.c",fullname="D:\\FIRMWARE_2014\\DAQ_MasterApp_M0\\src\\DAQ_MasterFunc_M0.c",line="497"},frame={level="1",addr="0x1b0002b2",func="main",file="../src/DAQ_MasterApp_M0.c",fullname="D:\\FIRMWARE_2014\\DAQ_MasterApp_M0\\src\\DAQ_MasterApp_M0.c",line="39"}]
673,355 (gdb) 



AND HERE THE ERROR (doing a step-over while breakpoint is still active)



758,190 40-exec-next --thread 1 1
758,200 40^running
758,200 *running,thread-id="1"
758,200 (gdb) 
758,645 &"Warning:\n"
758,645 &"Cannot insert hardware breakpoint 0.\n"
758,645 &"Could not insert hardware breakpoints:\n"
758,645 &"You may have requested too many hardware breakpoints/watchpoints.\n"
758,645 &"\n"
758,665 *stopped,frame={addr="0x1b0088b2",func="memcpy",args=[]},thread-id="1",stopped-threads="all"\

758,665 (gdb) 
758,675 41-stack-info-depth --thread 1 11
758,695 41^done,depth="3"
758,695 (gdb) 
758,715 42-thread-info 1
758,715 43-list-thread-groups
758,735 42^done,threads=[{id="1",target-id="Thread <main>",frame={level="0",addr="0x1b0088b2",func="memcpy",args=[]},state="stopped"}]
758,735 (gdb) 
758,745 43^done,groups=[{id="i1",type="process",pid="42000",executable="D:\\FIRMWARE_2014\\DAQ_MasterApp_M0\\Debug\\DAQ_MasterApp_M0.axf"}]
758,745 (gdb) 
758,809 44-stack-list-frames --thread 1 2 2
758,815 44^done,stack=[frame={level="2",addr="0x1b0002b2",func="main",file="../src/DAQ_MasterApp_M0.c",fullname="D:\\FIRMWARE_2014\\DAQ_MasterApp_M0\\src\\DAQ_MasterApp_M0.c",line="39"}]
758,815 (gdb) 
758,870 45-stack-list-frames --thread 1
758,875 45^done,stack=[frame={level="0",addr="0x1b0088b2",func="memcpy"},frame={level="1",addr="0x1b001212",func="eMMC_diskInfo",file="../src/DAQ_MasterFunc_M0.c",fullname="D:\\FIRMWARE_2014\\DAQ_MasterApp_M0\\src\\DAQ_MasterFunc_M0.c",line="497"},frame={level="2",addr="0x1b0002b2",func="main",file="../src/DAQ_MasterApp_M0.c",fullname="D:\\FIRMWARE_2014\\DAQ_MasterApp_M0\\src\\DAQ_MasterApp_M0.c",line="39"}]
758,875 (gdb) 
758,901 46-stack-list-frames --thread 1 0 2
758,905 46^done,stack=[frame={level="0",addr="0x1b0088b2",func="memcpy"},frame={level="1",addr="0x1b001212",func="eMMC_diskInfo",file="../src/DAQ_MasterFunc_M0.c",fullname="D:\\FIRMWARE_2014\\DAQ_MasterApp_M0\\src\\DAQ_MasterFunc_M0.c",line="497"},frame={level="2",addr="0x1b0002b2",func="main",file="../src/DAQ_MasterApp_M0.c",fullname="D:\\FIRMWARE_2014\\DAQ_MasterApp_M0\\src\\DAQ_MasterApp_M0.c",line="39"}]
758,905 (gdb) 




 
0 Kudos
Reply

1,571 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by lpcxpresso-support on Mon Jul 14 07:36:31 MST 2014

Quote: wlamers


I installed 7.3.0 and unticked "... and make path relative". "Alternate fix for debugger path" is selected by the way. But the problem is still there.


That I wouldn't expect. Please untick "Alternate fix for debugger path" (and ensure that "Translate debugger paths" is ticked). Then restart and try again.

With regards to breakpoints numbers, just be aware that in some situations the debugger will need a breakpoint unit  to single step - in others it won't. And that once you hit a  a breakpoint there is also the need to effectively temporarily disable it, single step off it, then put it back. This can all affect the usage of the limited number of breakpoint units in non-obvious ways.

With regards to additional information you could provide, please can you post the gdb-traces log (available from the same drop down as the Debug log - http://www.lpcware.com/content/faq/lpcxpresso/debug-log).  Please also list exactly what is shown in the breakpoints view.

Regards,
LPCXpresso Support

0 Kudos
Reply

1,571 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by wlamers on Mon Jul 14 07:05:23 MST 2014
Thanks for the info.

I am aware of the limited number of breakpoints. But the problem is present starting with just 1 breakpoint.

I installed 7.3.0 and unticked "... and make path relative". "Alternate fix for debugger path" is selected by the way. But the problem is still there.

Several months ago I decided to switch to the new version of LPCopen (coming from v1). Therefore I also started from scratch setting the projects using the new templates. Even with this new, fresh, setup the problem is persistent.

Unfortunately there are now no files, within all projects, with the same name having a breakpoint. Even the main.c files are replaced with names mathcing the project name.

Can I provide you with more information to get to the bottom of this? Unfortunately I cannot share the projects/workspace due to confidentiality reasons.
0 Kudos
Reply

1,571 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by lpcxpresso-support on Mon Jul 14 05:40:14 MST 2014
The Cortex-M0 cpu(s) in the LPC43xx only have a couple of breakpoint units, which means that it is quite easy to run out:

http://www.lpcware.com/content/faq/lpcxpresso/how-many-breakpoints-watchpoints

Anyway, I suspect that you are seeing breakpoints getting set across projects (where projects have files with the same filename). And the "Use full file path to set breakpoints: enabled" launch configuration option doesn't actually seem to work as expected in current versions of Eclipse CDT.

However if you update to LPCXpresso 7.3.0 released earlier today, you can then go to:

[list]
  [*]Windows->Preferences, LPCXpresso->Disassembly/Debug options
[/list]

and untick "...and make path relative”. Then restart LPCXpresso.

Note that we are currently considering making this the default in future LPCXpresso releases - so would be interested in hearing how you get on with it.

Regards,
LPCXpresso Support



0 Kudos
Reply