[Qt-creator] Remote GDB debugging.
tdhutt at gmail.com
Wed Jun 18 15:54:13 CEST 2014
PS: One more thing for people that may be using a SEGGER or nRF51822 or
similar. If you want your firmware to be flashed every time you start
debugging, add "load" to the initial commands like this:
mon speed 10000
mon endian little
mon flash download = 1
mon flash device = NRF51822
mon reset 0
On 18 June 2014 14:45, Tim Hutt <tdhutt at gmail.com> wrote:
> Oh wow, that finally did the trick! Everything works! So in summery here
> were the things that I wish I had known/need to be fixed:
> 1. You need to build a gdb with arm and python support. There is a
> Makefile in the QtCreator repo which will download all the code and build
> it for you nicely.
> 2. But first you need to change the targets to "targets=arm-none-eabi" and
> the hard-coded arch on line 113 to "arm-none-eabi".
> 3. If using QBS you must have "application" in your "type" property. It
> might need to be first; I'm not sure. But it doesn't work if "application"
> is implicitly built - it must be explicitly listed.
> 4. You must disable QML debugging in the run configuration or you'll get
> an empty error dialog when debugging and it won't work.
> 5. You must use the appropriate "monitor" commands in the device
> configuration, otherwise breakpoints won't do anything:
> mon speed 10000
> mon endian little
> mon flash download = 1
> mon flash device = NRF51822
> mon reset 0
> 6. You must enable "Use asynchronous mode to control the inferior" or
> QtCreator will crash when you pause execution or set breakpoints while it's
> 7. You probably want to disable "Show a message box when receiving a
> signal" or you'll get a pointless dialog every time you pause execution.
> Phew! Well, now that it works I'm pretty happy! That was a lot of effort
> though with more than a few Qt Creator bugs. I guess BareMetal is pretty
> new. Thanks very much for writing it Tim and thanks everyone for your help!
> Hopefully at some point I will have time to put this in a nice tutorial
> form on the Qt wiki, but I guess this email will be searchable by google at
> least. Here's some keywords: Nordic nRF51822 nRF51422 ARM Cortex SEGGER Qt
> Creator QBS debug GDB.
> PS: I don't think I ever solved the --datadirectory problem, but I'll
> leave that for now.
> On 18 June 2014 14:29, Tim Sander <tim at krieglstein.org> wrote:
>> Hi Tim
>> Am Mittwoch, 18. Juni 2014, 11:12:48 schrieben Sie:
>> > Oh wow I finally got it to work! The key was to use the initialisation
>> > commands provided by Nordic (who make the nRF51822)!:
>> > mon speed 10000
>> > mon endian little
>> > mon flash download = 1
>> > mon flash device = NRF51822
>> > mon reset 0
>> > However, I have no discovered a segfault in QtCreator! It crashes
>> > ("qtcreator.exe has stopped working") if you do either of:
>> > 1. Manually pause program execution.
>> > 2. Add a breakpoint while the program is running.
>> I guess thats a Windows problem, but that can be omitted if you *enable*
>> Tools->Options->Debugger->GDB Extended->"Use asynchronous mode to control
>> > So close!
>> On the mark with the above config change :-).
>> > On 18 June 2014 10:58, Tim Hutt <tdhutt at gmail.com> wrote:
>> > > The same files is generated in both cases though... If it's checking
>> > > the string "application" in the types list, I think that should just
>> > > removed. If it's seeing if the "last" build item is an "application",
>> > > if
>> > > any of the explicitly specified types are "application", then I think
>> > > should be changed to search the entire build tree for the
>> > > node.
>> > >
>> > > Anyway...
>> > >
>> > > I forgot to mention that I also get this error when clicking the debug
>> > > button:
>> > >
>> > > [image: Inline images 1]
>> > >
>> > > What is the "inferior"?
>> > >
>> > > I also tried using "break main.cpp:51" from the official Gnu ARM
>> > > install (which is the one the chip maker recommend so I know it should
>> > > work). It had the same effect as break-insert did from QtCreator... So
>> > > maybe it's just that Eclipse (what they use) knows to use monitor
>> > > instead of break? Or maybe they tell gdb how break should behave?
>> You should also *disable* Tools->Options->Debugger->GDB->"Show a message
>> when receiving a signal" to get rid of the message box when hitting a
>> Best regards
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Qt-creator