Code::Blocks

User forums => Embedded development => Topic started by: bartddgd on March 03, 2013, 08:42:14 pm

Title: Debugging with Segger JLINK
Post by: bartddgd on March 03, 2013, 08:42:14 pm
Hi,

I'm using Code::Blocks together with the Yagarto ARM toolchain. Compiling and linking is working just fine using my custom Makefile.

Now I'm trying to get JTAG programming and debugging to work. As JTAG adapter I use a Segger JLINK EDU. Flashing works fine, but debugging always fails :-(

In the "Before connection" field of the GDB config in Code::Blocks I have:

file ./obj/lpc2387_88_test.elf
set mem inaccessible-by-default off
target remote localhost:2331
monitor flash device = LPC2387
monitor flash breakpoints = 1
monitor flash download = 1
monitor endian little
monitor speed auto
monitor reset
monitor long 0xE01FC040 = 1
load

The "After connection" field contains:

monitor reset
thbreak main
continue

My program gets uploaded and starts running if I remove the "thbreak main" line. If I leave this line in, the program gets uploaded and even seems to stop at main(), but from that point on no other debug function in Code::Blocks works. All the stepping options are greyed out and I cannot terminate the debug session. I have to close and restart Code::Blocks and the Segger GDB server.

Any ideas how to get debugging to work in Code::Blocks?

Best regards,
Bernd
Title: Re: Debugging with Segger JLINK
Post by: oBFusCATed on March 03, 2013, 09:13:33 pm
monitor reset
thbreak main
continue
Why don't you use the breakpoint and continue/step UI in codeblocks?
They should work just fine. The before/after connection options should be used only for setup not for controlling the execution.
Title: Re: Debugging with Segger JLINK
Post by: bartddgd on March 03, 2013, 09:27:35 pm
So, you mean I should just have the "Before" options for uploading the firmware and no options in "After"?.

Just tried that: In the "Before" options I added "monitor reset" as the last line (right behind "load") and set a breakpoint in the GUI somewhere in my main while() loop.

After clicking on the "Debug/continue" button the GDB connection gets started and the firmware is uploaded. I can see a small window from Segger doing the flash upload for a short time. Then in the GUI my startup.s file gets focused with the reset entry address and program is still stopped and non of the debug icons work (most of them are greyed out).

If I repeat the procedure and add "continue" at the end of the "Before" options the program gets uploaded an started, but again none of the debug options work. Altough this time  none is greyed out.
Title: Re: Debugging with Segger JLINK
Post by: oBFusCATed on March 03, 2013, 09:50:56 pm
Can you post the full log from the debugger (you should enable it first!)?
And yes, putting continue/break or other similar commands will mess up the communication between C::B and gdb.
Title: Re: Debugging with Segger JLINK
Post by: bartddgd on March 04, 2013, 04:18:40 pm
Here is what's happening when I press the "Debug/Continue" button:

Code: [Select]
Building to ensure sources are up-to-date
Selecting target:
All
Adding source dir: D:\Devel\X711_Test\
Adding source dir: D:\Devel\X711_Test\
Adding file: D:\Devel\X711_Test\obj\lpc2387_88_test.sys
Changing directory to: D:/Devel/X711_Test/
Set variable: PATH=.;C:\yagarto-20121222\bin;C:\yagarto-20121222;C:\Program Files (x86)\AMD APP\bin\x86_64;C:\Program Files (x86)\AMD APP\bin\x86;C:\Program Files (x86)\VMware\VMware vSphere CLI\Perl\site\bin;C:\Program Files (x86)\VMware\VMware vSphere CLI\Perl\bin;C:\Perl64\site\bin;C:\Perl64\bin;C:\MentorGraphics\9.3.1PADS\SDD_HOME\common\win32\bin;C:\MentorGraphics\9.3.1PADS\SDD_HOME\common\win32\lib;C:\Program Files\Common Files\Microsoft Shared\Windows Live;C:\Program Files (x86)\Common Files\Microsoft Shared\Windows Live;C:\WinAVR-20100110\bin;C:\WinAVR-20100110\utils\bin;C:\Windows\System32;C:\Windows;C:\Windows\System32\wbem;C:\Windows\System32\WindowsPowerShell\v1.0;C:\Program Files (x86)\ATI Technologies\ATI.ACE\Core-Static;C:\Program Files\Microsoft Windows Performance Toolkit;C:\Program Files (x86)\IVI Foundation\IVI\Bin;C:\Program Files\IVI Foundation\IVI\Bin;C:\Program Files\IVI Foundation\VISA\Win64\Bin;C:\Program Files (x86)\IVI Foundation\VISA\WinNT\Bin;C:\Program Files\TortoiseSVN\bin;C:\Program Files (x86)\Windows Live\Shared;C:\Program Files (x86)\Common Files\Acronis\SnapAPI;C:\MentorGraphics\9.3.1PADS\MGC_HOME.ixn\bin;C:\MentorGraphics\9.3.1PADS\MGC_HOME.ixn\lib;C:\Program Files (x86)\doxygen\bin;C:\Program Files (x86)\GTK2-Runtime\bin;C:\Program Files (x86)\MiKTeX 2.9\miktex\bin;C:\Program Files (x86)\Graphviz 2.28\bin;C:\Program Files\doxygen\bin;C:\Program Files (x86)\Haufe\iDesk\iDeskService;C:\yagarto-tools-20121018\bin;C:\Program Files (x86)\Flash Magic;C:\Program Files (x86)\Acronis\BackupAndRecovery;C:\Program Files (x86)\IDM Computer Solutions\UltraEdit;C:\Program Files (x86)\IDM Computer Solutions\UltraCompare;c:\Program Files (x86)\gs\gs9.05\bin

[debug]Command-line: C:\yagarto-20121222\bin\arm-none-eabi-gdb.exe -nx -fullname  -quiet  -args D:/Devel/X711_Test/obj/lpc2387_88_test.sys
[debug]Working dir : D:\Devel\X711_Test

Starting debugger: C:\yagarto-20121222\bin\arm-none-eabi-gdb.exe -nx -fullname  -quiet  -args D:/Devel/X711_Test/obj/lpc2387_88_test.sys
done

[debug]> set prompt >>>>>>cb_gdb:

Registered new type: wxString
Registered new type: STL String
Registered new type: STL Vector
Setting breakpoints

[debug]D:/Devel/X711_Test/obj/lpc2387_88_test.sys: No such file or directory.
[debug](gdb) >>>>>>cb_gdb:
[debug]> show version
[debug]GNU gdb (GDB) 7.5.1
[debug]Copyright (C) 2012 Free Software Foundation, Inc.
[debug]License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
[debug]This is free software: you are free to change and redistribute it.
[debug]There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
[debug]and "show warranty" for details.
[debug]This GDB was configured as "--host=i686-pc-mingw32 --target=arm-none-eabi".
[debug]For bug reporting instructions, please see:
[debug]<http://www.gnu.org/software/gdb/bugs/>.
[debug]>>>>>>cb_gdb:
[debug]> set confirm off

Debugger name and version: GNU gdb (GDB) 7.5.1

[debug]>>>>>>cb_gdb:
[debug]> set width 0
[debug]>>>>>>cb_gdb:
[debug]> set height 0
[debug]>>>>>>cb_gdb:
[debug]> set breakpoint pending on
[debug]>>>>>>cb_gdb:
[debug]> set print asm-demangle on
[debug]>>>>>>cb_gdb:
[debug]> set unwindonsignal on
[debug]>>>>>>cb_gdb:
[debug]> set print elements 0
[debug]>>>>>>cb_gdb:
[debug]> set disassembly-flavor att
[debug]No symbol table is loaded.  Use the "file" command.
[debug]>>>>>>cb_gdb:
[debug]> catch throw
[debug]No symbol table is loaded.  Use the "file" command.
[debug]Catchpoint 1 (throw)
[debug]>>>>>>cb_gdb:
[debug]> source C:\Users\bart\AppData\Local\CodeBlocks\share\codeblocks/scripts/stl-views-1.0.3.gdb
[debug]>>>>>>cb_gdb:
[debug]> directory D:/Devel/X711_Test/
[debug]Source directories searched: D:/Devel/X711_Test;$cdir;$cwd
[debug]>>>>>>cb_gdb:
[debug]> file ./obj/lpc2387_88_test.elf
[debug]Reading symbols from D:\Devel\X711_Test\obj\lpc2387_88_test.elf...done.
[debug]>>>>>>cb_gdb:
[debug]> set mem inaccessible-by-default off
[debug]>>>>>>cb_gdb:
[debug]> target remote localhost:2331
[debug]Remote debugging using localhost:2331
[debug]Vectors () at src/lpc23xx_startup.s:120
[debug]D:\Devel\X711_Test\src\lpc23xx_startup.s:120:3990:beg:0x0
[debug]>>>>>>cb_gdb:
[debug]> monitor flash device = LPC2387

At D:\Devel\X711_Test\src\lpc23xx_startup.s:120

[debug]> monitor flash device = LPC2387
[debug]Selecting device: LPC2387
[debug]Selecting device: LPC2387
[debug]>>>>>>cb_gdb:>>>>>>cb_gdb:
[debug]> monitor flash breakpoints = 1
[debug]Flash breakpoints enabled
[debug]>>>>>>cb_gdb:
[debug]> monitor flash download = 1
[debug]Flash download enabled
[debug]>>>>>>cb_gdb:
[debug]> monitor endian little
[debug]Target endianess set to "little endian"
[debug]>>>>>>cb_gdb:
[debug]> monitor speed auto
[debug]Select auto target interface speed (65535 kHz)
[debug]>>>>>>cb_gdb:
[debug]> monitor reset
[debug]Resetting target
[debug]>>>>>>cb_gdb:
[debug]> monitor long 0xE01FC040 = 1
[debug]Writing 0x00000001 @ address 0xE01FC040
[debug]>>>>>>cb_gdb:
[debug]> load
[debug]Loading section .text, size 0xa94 lma 0x0
[debug]Start address 0x0, load size 2708
[debug]Transfer rate: 377 KB/sec, 2708 bytes/write.
[debug]>>>>>>cb_gdb:
[debug]> monitor reset
[debug]Resetting target
[debug]>>>>>>cb_gdb:
[debug]> break "D:/Devel/X711_Test/src/app_main.c:123"
[debug]Breakpoint 2 at 0x494: file src/app_main.c, line 123.
[debug]>>>>>>cb_gdb:
[debug]> run
[debug]The "remote" target does not support "run".  Try "help target" or "continue".
[debug]>>>>>>cb_gdb:

This is what I see in the Segger GDB server log window:

Code: [Select]
SEGGER J-Link GDB Server V4.60a

JLinkARM.dll V4.60a (DLL compiled Jan 16 2013 17:15:30)

Connecting to J-Link...
J-Link is connected.
Firmware: J-Link ARM V8 compiled Nov 14 2012 22:34:52
Hardware: V8.00
S/N: 268004267
OEM: SEGGER-EDU
Feature(s): FlashBP, GDB
Checking target voltage...
Listening on TCP/IP port 2331
Connecting to target...
J-Link found 1 JTAG device, Total IRLen = 4
JTAG ID: 0x4F1F0F0F (ARM7)
Connected to target
Waiting for GDB connection...Connected to 127.0.0.1
Reading all registers
Read 4 bytes @ address 0x00000000 (Data = 0xE59FF018)
Selecting device: LPC2387
Selecting device: LPC2387
Flash breakpoints enabled
Flash download enabled
Target endianess set to "little endian"
Select auto target interface speed (65535 kHz)
Resetting target
Writing 0x00000001 @ address 0xE01FC040
Downloading 2708 bytes @ address 0x00000000
WARNING: CPU is running at low speed (4017 kHz).
Resetting target
Read 4 bytes @ address 0x00000000 (Data = 0xE59FF018)
Read 4 bytes @ address 0x000003A0 (Data = 0xE3A03001)
Read 4 bytes @ address 0x00000494 (Data = 0xE51B3008)


Contents of GDB "Before" commands:

Code: [Select]
file ./obj/lpc2387_88_test.elf
set mem inaccessible-by-default off
target remote localhost:2331
monitor flash device = LPC2387
monitor flash breakpoints = 1
monitor flash download = 1
monitor endian little
monitor speed auto
monitor reset
monitor long 0xE01FC040 = 1
load
monitor reset

The firmware gets uploaded, the editor shows the startup.s file with a small little yellow triangle on the reset entry vector line.
The buttons "Break debugger" and "Stop debugger" are available, but clicking on them has no effect. All other debug buttons are greyed out.

Title: Re: Debugging with Segger JLINK
Post by: oBFusCATed on March 04, 2013, 04:26:55 pm
Contents of GDB "Before" commands:

Code: [Select]
file ./obj/lpc2387_88_test.elf
set mem inaccessible-by-default off
target remote localhost:2331
monitor flash device = LPC2387
monitor flash breakpoints = 1
monitor flash download = 1
monitor endian little
monitor speed auto
monitor reset
monitor long 0xE01FC040 = 1
load
monitor reset

C::B still think you're not in remote debugging mode, because you've setup the connection parameters manually using gdb commands.
Please use the UI, for things like ip, domain, port, speed, etc. Then it should work.
Title: Re: Debugging with Segger JLINK
Post by: bartddgd on March 04, 2013, 04:34:10 pm
Thanks a lot! Now I understood what you meant.

After removing the "target remote localhost:2331" line from the "Before" commands and adding "localhost" and port 2331 in the "Remote connection" tab of the debugger project settings everything works fine. The program break where it should and single stepping also works.

Again, thanks for your quick help!

Best regards,
Bernd
Title: Re: Debugging with Segger JLINK
Post by: dirk_1980 on March 08, 2013, 03:08:58 pm
Maybe the easiest way is to use the emIDE.
It is a Code::Blocks clone with some really nice changes to CB.
And there is a special J-Link Plugin.


Title: Re: Debugging with Segger JLINK
Post by: oBFusCATed on March 08, 2013, 03:50:42 pm
Maybe the easiest way is to use the emIDE.
This is something new, someone has forked C::B instead of providing patches...
Title: Re: Debugging with Segger JLINK
Post by: MortenMacFly on March 09, 2013, 01:48:16 pm
This is something new, someone has forked C::B instead of providing patches...
dunno - it seems its based on 12.11 sources with additional plugins.

But still: Weird (s)he didn't start here in the forums...
Title: Re: Debugging with Segger JLINK
Post by: MortenMacFly on March 09, 2013, 04:22:33 pm
But still: Weird (s)he didn't start here in the forums...
...interesting to notice: There is a "debug locals" dialog implemented. Maybe worth a look...
Title: Re: Debugging with Segger JLINK
Post by: oBFusCATed on March 09, 2013, 04:50:13 pm
...interesting to notice: There is a "debug locals" dialog implemented. Maybe worth a look...
It is not general and not reusing the wxPropGrid code...
Title: Re: Debugging with Segger JLINK
Post by: dirk_1980 on March 11, 2013, 09:27:04 am
I think he sad something like:
 
He forked C::B because You (CB)  didn't used his patches.

But i don't know what is right.

For me it would be the best if YOU could use his patches and Plugin directly inside CB.
Title: Re: Debugging with Segger JLINK
Post by: oBFusCATed on March 11, 2013, 05:37:50 pm
For me it would be the best if YOU could use his patches and Plugin directly inside CB.
Some of them might get in, but not all.
Title: Re: Debugging with Segger JLINK
Post by: Grad on March 14, 2013, 04:01:32 pm
Maybe the easiest way is to use the emIDE.
This is something new, someone has forked C::B instead of providing patches...

There are a lot forked code::blocks just for embedded fun.

http://www.emide.org
http://www.emblocks.org
http://www.imagecraft.com

I guess they all acknowledge the strength of code::blocks but are searching for a more embedded tailored  environment.

I think, it's a compliment.
Title: Re: Debugging with Segger JLINK
Post by: oBFusCATed on March 26, 2013, 07:53:27 pm
http://www.emblocks.org
http://www.imagecraft.com
I don't think these two comply with the GPL-3 license we are using.
Can anyone who has tried them, tell me if they ship the source code of the IDE as required by the license?
Title: Re: Debugging with Segger JLINK
Post by: Pecan on March 27, 2013, 01:54:01 pm
ImageCraft does not charge for CB.
It only charges for its compilers (ARM.AVR)
The CB source is downloadable via link.

GPL does not state that the source has to be included with the object, only that "you must also provide them with a way to get the source."


http://www.gnu.org/licenses/quick-guide-gplv3.html
Quote
One of the fundamental requirements of the GPL is that when you distribute object code to users, you must also provide them with a way to get the source. GPLv2 gave you a few ways to do this, and GPLv3 keeps those intact with some clarification. It also offers you new ways to provide source when you convey object code over a network. For instance, when you host object code on a web or FTP server, you can simply provide instructions that tell visitors how to get the source from a third-party server. Thanks to this new option, fulfilling this requirement should be easier for many small distributors who only make a few changes to large bodies of source.
Title: Re: Debugging with Segger JLINK
Post by: oBFusCATed on March 27, 2013, 03:08:18 pm
ImageCraft does not charge for CB.
It only charges for its compilers (ARM.AVR)
The CB source is downloadable via link.
Good, I've not seen the link, so I couldn't verify that they comply with the license.
Do they have any changes to C::B's code?

http://www.emblocks.org provides a single executable which I cannot run to see if they provide the source with it.
Can anyone who has used it tell me if this is the case?
Title: Re: Debugging with Segger JLINK
Post by: Grad on March 27, 2013, 06:42:47 pm
ImageCraft does not charge for CB.
It only charges for its compilers (ARM.AVR)
The CB source is downloadable via link.

GPL does not state that the source has to be included with the object, only that "you must also provide them with a way to get the source."


Yes, the same for EmBlocks accept it doesn't charge for anything.
There are links at the forum, but the code is still heavily under construction.

It's the same as here (http://forums.codeblocks.org/index.php/topic,12360.msg83988.html#msg83988).

Because there are a lot of changes to make EmBlocks an embedded development suite (GDB, GCC, wxWidgets, STlink-gdb, etc) and it is still continuously changing so the best way to publish this is not fully clear right now.

Title: Re: Debugging with Segger JLINK
Post by: oBFusCATed on March 27, 2013, 11:56:04 pm
Yes, the same for EmBlocks accept it doesn't charge for anything.
There are links at the forum, but the code is still heavily under construction.
GPL doesn't prevent charging, it prevents distributing binaries without the code.

Because there are a lot of changes to make EmBlocks an embedded development suite (GDB, GCC, wxWidgets, STlink-gdb, etc) and it is still continuously changing so the best way to publish this is not fully clear right now.
Why not use github.com or sf.com or anything similar? :)
This way people can see what is changing and can provide comments, patches, etc.

Why wxWidgets is related to embedded develoment?

Grad: are you a EmBlocks developer?
Title: Re: Debugging with Segger JLINK
Post by: Grad on March 28, 2013, 07:20:23 am
Why wxWidgets is related to embedded develoment?

It is not, well, ... it is equally related to embedded as desktop  :)

I have changed a lot of wxWidgets code on the MSW part but also generic. There were some annoying bugs (like in the statusbar handling of text) but I also freely added stuff or changed behaviour of it.
I didn't like, as an example, the handling of menus. Why different approach for a menu with checkboxes than with icon's? But the changes of wxWidgets also changed the rest of the code, different function calls etc etc.

The objectives are a little bit different here. The goal (mission statement is a bit heavy I guess) is to make an user friendly embedded development suite for windows. An embedded development suite without all kind of tweaks etc. Working out of the box with the same experiences as if you would use uVision (my favourite at that moment). Once started, almost 2 years ago, I came across all kind of problems. I first kept a list with changes or bugs that I found but that was not workable, I was more administrating than programming. So the end result became more important than the backward compatibility with the used components like e.g. wxWidgets or codeblocks.      

But EmBlocks is only suitable for embedded, it can't build desktop applications. All the desktop related stuff is removed from the source pool (like resource compiler, dynamic libraries etc). In the next release I will shrink it further by removing the 22px toolbar and the Batch/make file support. There is not much left of the original codeblocks code of 2 years ago and it is drifting further away with the day  ::)

Because it is a one man project, Github etc is at this moment a bit too much overhead. I have also a daytime job to do.

So yes, I wrote it.
Title: Re: Debugging with Segger JLINK
Post by: oBFusCATed on March 28, 2013, 08:14:38 am
So you say that EmBlocks uses customized version of wxWidgets?

I'm interested in looking at the code, btw, some things might be worth to integrate back.
I might integrate your version of the Examine memory windows, for example, because it looks good.
The toolbars and the overall look of the IDE look cool in windows. Is this possible with vanilla wxwidgets?
Title: Re: Debugging with Segger JLINK
Post by: Grad on March 28, 2013, 09:11:48 am
So you say that EmBlocks uses customized version of wxWidgets?
The toolbars and the overall look of the IDE look cool in windows. Is this possible with vanilla wxwidgets?

Yes, the wxWidgets is heavily customized (like a lot of us do) which is allowed under the wxWindows license 3.1.
You may change the library and it is allowed to only provide the binaries so that gives space at the wxWidget part :).

You have to add styling to it and the MSW need additional low-level stuff.

I'm not familiar with vanilla, never heard of it.

Title: Re: Debugging with Segger JLINK
Post by: oBFusCATed on March 28, 2013, 09:26:16 am
I'm not familiar with vanilla, never heard of it.
Vanilla means clean upstream version.
Modifying wxWidgets isn't fun in the longer run.

Still I'd like to see the sources. If you like to show them to me you can p.m. me with you e-mail and I can send you a message,
this is if you don't want to bother with putting them online for everyone (no matter that this is required by the license).
Title: Re: Debugging with Segger JLINK
Post by: Grad on March 28, 2013, 10:59:19 am
No problem, I think it's better for now that you point out in which part you are interested in.
If it is using added wxWidget stuff, like the memory window, I could isolate that. Or I could help you with porting that part to code::blocks.

I think that you have my email (it was a part of the registration). I'm quite busy the next couple of weeks but after that I will have time.


Cheers



 



Title: Re: Debugging with Segger JLINK
Post by: Pecan on March 28, 2013, 02:44:00 pm
ImageCraft does not charge for CB.
It only charges for its compilers (ARM.AVR)
The CB source is downloadable via link.
Good, I've not seen the link, so I couldn't verify that they comply with the license.
Do they have any changes to C::B's code?

http://www.emblocks.org provides a single executable which I cannot run to see if they provide the source with it.
Can anyone who has used it tell me if this is the case?

ImageCraft mods to CB consists mainly of directing events to their plugins which in-turn writes their own (additional) project file.
Then their compilers read their own project file.

Not too interesting.