[Lazarus] Gdb and openocd via lazarus
Justin Smyth
delphian at smythconsulting.net
Tue Jun 17 12:49:32 CEST 2014
Thanks
My status right now I about to move into getting it working when lazarus
calls GDB. I didn't know about GDB doing the flash instead
I just wanted to make sure both gdb and openocd were talking correctly and I
had that stage correct. ( it seems to work except openocd bitches about the
checksum of 0x00000000 not matching the calculated value of the file)
Heres the output in question - from when open up openocd with a
configuration file that I deleted the bit from Flash on wards
Two questions LPC Vector can I ignore this , and the time out for gdb ( I
tried to add --eval-command="set remotetimeout 60" and it didn't make any
difference )
C:\LazarusExtras\OpenOCD>openocd.exe -f ocd.cfg
Open On-Chip Debugger 0.8.0 (2014-04-28-08:42)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
adapter speed: 10 kHz
adapter_nsrst_delay: 200
Info : This adapter doesn't support configurable speed
Info : STLINK v2 JTAG v14 API v2 SWIM v3 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 3.191053
Info : lpc1343.cpu: hardware has 6 breakpoints, 4 watchpoints
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x1fff0104 msp: 0x10000ffc
-----> now I start gdb in a separate dos cmd
C:\LazarusExtras\gdb\bin>arm-none-eabi-gdb myprogram.elf
--eval-command="target
extended :3333" --eval-command="monitor reset halt" --eval-command="set mem
in
accessible-by-default off" --eval-command="load"
GNU gdb (crosstool-NG linaro-1.13.1-4.9-2014.05 - Linaro GCC 4.9-2014.05)
7.6.1-
2013.10
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=i586-host_pc-mingw32msvc
--target=arm-none-ea
bi".
For bug reporting instructions, please see:
<https://bugs.launchpad.net/gcc-linaro>...
Reading symbols from C:\LazarusExtras\gdb\bin\myprogram.elf...done.
Remote debugging using :3333
0x1fff0104 in ?? ()
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x1fff0104 msp: 0x10000ffc
Loading section .text, size 0x7cc lma 0x0
Loading section .data, size 0x98 lma 0x7cc
Start address 0x784, load size 2148
Transfer rate: 740 bytes/sec, 1074 bytes/write.
(gdb)
Now the openocd windows comes up with
Info : accepting 'gdb' connection from 3333
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x1fff0104 msp: 0x10000ffc
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x1fff0104 msp: 0x10000ffc
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x10000004 msp: 0x100000b4
---> Warn : Verification will fail since checksum in image (0x00000000) to
be written to flash is different from calculated vector checksum
(0xefffba67). <---
----> Warn : To remove this warning modify build tools on developer PC to
inject correct LPC vector checksum. <----
*** Warn : keep_alive() was not invoked in the 1000ms timelimit. GDB alive
packet not sent! (1785). Workaround: increase "set remotetimeout" in GDB ***
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x1fff0104 msp: 0x10000ffc
-----Original Message-----
From: Michael Ring [mailto:mail at michael-ring.org]
Sent: Tuesday, 17 June 2014 7:39 PM
To: delphian at smythconsulting.net; Lazarus mailing list
Subject: Re: [Lazarus] Gdb and openocd via lazarus
TUI is a rather seldomly used option, I also saw that some linux distros do
not support it. If you want it you will perhaps really need to build a
version of gdb for yourself.
Your openocd file looks fine on first glance, I would propably not do the
flash command manually and instead use gdb's command to do the flashing, but
in the end the result should be pretty much the same.
Using gdb for flashing is perhaps a little better because you do not need to
change your openocd config file when you binary file changes. If I find the
time tonight I will see if this works, but I will not promise anything ;-)
So what is your status right now, can you already single step through your
code and does entering break main cont
work ?
Michael
Am 16.06.14 16:03, schrieb Justin Smyth:
> Thanks Michael
>
>
> I got better results from using the GDB from the tool chain binaries
> from linaro.
>
> Is it normal for TUI not to be supported in the arm eabi version ?
>
> I can now start openocd8 , and start gdb and I see both of them talk
> to each other ( I want to see gdb connect correctly then I will move
> onto getting lazarus to connect once I have it working in two dos
> prompts on my windows vm )
>
> My open ocd configuration file looks like this ( does this look right ?
> anything missing or do I need to change anything ? )
>
>
> source [find interface/stlink-v2.cfg]
> set CHIPSERIES lpc1300
> set TRANSPORT hla_swd
> set CPUROMSIZE 0x8000
> set CPURAMSIZE 0x2000
> source [find target/lpc1343.cfg]
>
> init
> reset init
>
> flash write_image erase unlock myprogram.elf 0 elf
>
> reset run
> reset init
>
>
> Kind Regards
>
>
> Justin
>
> -----Original Message-----
> From: Michael Ring [mailto:mail at michael-ring.org]
> Sent: Monday, 16 June 2014 6:33 PM
> To: Lazarus mailing list
> Subject: Re: [Lazarus] Gdb and openocd via lazarus
>
> There's an excellent Page on using gdb with freepascal on the wiki:
>
> http://wiki.lazarus.freepascal.org/GDB_Debugger_Tips,
>
> when you scroll down there's a list of recommended gdb versions.
>
> Rebuilding gdb from source is peace of cake on linux and mac, I never
> really tried it on a windows machine , but this link should help:
>
> http://dev.zhourenjian.com/blog/2009/03/11/compiling-gdb-debugger-in-w
> indows
> .html
>
> or have a look at the linaro toolchain, they also have a lot of
> different precompiled versions for windows, their builds:
>
> https://releases.linaro.org/14.05/components/toolchain/binaries
>
> When you start at https://releases.linaro.org/ you can see all the
> different versions available.
>
> Michael
>
> Am 14.06.14 17:42, schrieb Justin Smyth:
>> Michael
>>
>> A few questions for you , I am back now able to proceeded with my arm
>> project using lazarus ( laptop has been dead 3 weeks needed a
>> replacement motherboard off ebay from the USA).
>>
>>
>> The arm GDB I am using I got from code sorcery ( arm-none-eabi )
>>
>>
>> C:\LazarusExtras\gdb\bin>arm-none-eabi-gdb.exe
>> GNU gdb (Sourcery G++ Lite 2010.09-51) 7.2.50.20100908-cvs Copyright
>> (C) 2010 Free Software Foundation, Inc.
>> License GPLv3+: GNU GPL version 3 or later
>> <http://gnu.org/licenses/gpl.html>
>> This is free software: you are free to change and redistribute it.
>> There is NO WARRANTY, to the extent permitted by law. Type "show
copying"
>> and "show warranty" for details.
>> This GDB was configured as "--host=i686-mingw32 --target=arm-none-eabi".
>> For bug reporting instructions, please see:
>> <https://support.codesourcery.com/GNUToolchain/>.
>>
>>
>>
>> Is this the best version to use ?
>>
>> Could I compile the latest version of gdb from there svn ? would that
>> work out of the box - I've been able to compile fpc ok for arm from svn.
>>
>>
>> I just want to make sure the copy of gdb for arm I using can stop on
>> breakpoints etc.
>>
>>
>> Justin Smyth
>>
>>
>>
>> -----Original Message-----
>> From: Koenraad Lelong [mailto:lazarus2 at de-brouwerij.be]
>> Sent: Friday, 30 May 2014 6:06 AM
>> To: lazarus at lists.lazarus.freepascal.org
>> Subject: Re: [Lazarus] Gdb and openocd via lazarus
>>
>> op 28-05-14 13:57, Michael Ring schreef:
>>> Here's how I call gdb:
>>>
>>> arm-none-eabi-gdb hello.elf --tui --eval-command="target extended :3333"
>>> --eval-command="monitor reset halt" --eval-command="set mem
>>> inaccessible-by-default off" --eval-command="load"
>>>
>>>
>>> This loads the binary, you should end up with the debugger showing
>>> you your source code.
>>>
>>> Now try stepping through the code, if all is fine then great,
>>> problem is in the integration of gdb.
>>>
>>> Stept I use:
>>> break main
>>> cont
>>>
>>> step
>>>
>> This all works. Tomorrow I will try to send those commands with mseide.
>>
>> Many thanks.
>>
>> Koenraad
>>
>>
>> --
>> _______________________________________________
>> Lazarus mailing list
>> Lazarus at lists.lazarus.freepascal.org
>> http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
>>
>>
>>
>> --
>> _______________________________________________
>> Lazarus mailing list
>> Lazarus at lists.lazarus.freepascal.org
>> http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
>
> --
> _______________________________________________
> Lazarus mailing list
> Lazarus at lists.lazarus.freepascal.org
> http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
>
>
>
> --
> _______________________________________________
> Lazarus mailing list
> Lazarus at lists.lazarus.freepascal.org
> http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
More information about the Lazarus
mailing list