[Qt-creator] [Fwd: Re: BareMetal Target Plugin Configuration]
alexis.jeandet at lpp.polytechnique.fr
Fri Dec 27 14:47:17 CET 2013
As a complement to what I send to Tim yesterday, here is a link to my
kit. It's still under development and far away to be releasable!
If anybody want to have a look at it, it works only on linux_x64 and if
you put it in /opt/libuc2 then you can add this as Qt kit from creator.
In my understanding the run setting is the place you start your gdb
server with all the options (gdb port address), a good feature could be
to add it automatically from a wizard or the Bare metal plugin.
Thanks for your answer. I am already quite familiar with debugging on
stm32 with gdb, I have one setup with nemiver which works fine. From
what you explain me, it seems that my configuration was good so after
more investigations, the problem come from my custom Qt kit. In fact
this is not just a fake SDK, it contains a qmake with customs mkspec
files and libraries for arm(MMUless) processors, that's why I use it.
I made it to allow users to create simple qt projects for boards like
STM32F4* without big modifications in the .pro file all the gcc and lib
configs are in my kit.
It seems that Qtcreator needs to detect the kit's abi to setup the gdb
client which seems weird to me because you can tel it which gdb to use.
In my case I tried a funny thing, I copied a random lib file from my
folder to Mykit/bin/libQtCore.a and then qtcreator detect my kit as
arm-linux-generic-elf-32bit instead of amr-unknown-unknown-unknown-32bit
the detected ABI for the used gcc and gdb.
Is there any thing possible on Qtcreator side to have a more flexible
kit detection? I didn't plan to switch to QBS for now, I don't know yet
if it can replace what I do with my custom kit and qmake?
Le samedi 21 décembre 2013 à 15:51 +0100, Tim Sander a écrit :
> Hi Jeandet
> > We discuss a little about your plugin on the Qt mailing list, first
> > plugin a very good feature for Qtcreator.
> > I tried to look how to use it, I started with this help:
> > l.html
> Well you need a hardware debbuger backend which qtcreator needs to
> The backend is not started automatically as some of the hw debuggers
> their own gui and it seemed the simplest to just let the user start
> debugger on its own.
> I have tested OpenOCD and some comercial offerings.
> > But few things are unclear to me, is this version allowing me to
> > (step by step and breakpoint) my code? If yes I don't understand
> > are all the fields for the configuration:
> > For the device I use the same as you (localhost same port ...)
> This should work. Basically you can test your hw debugger by starting
> gdb on command line and test the the session over there.
> The commands would be
> gdb-arm-none-eabi executable
> target remote localhost:<portnr>
> monitor reset halt
> monitor reset halt
> > But for for the kit I have my own qt kit for STM32F4 which works. I
> > set the debugger to arm-none-eabi-gdb.
> So you are using the qmake build system. I would recommend you to use
> qbs build system where you don't need a fake-qt setup.
> > Then for the run settings I really don't understand. In my case use
> > st-util -p 3333 on linux to start a gdb server, if I put this as
> > executable, on run it load the code on the target but on debug it
> > that /usr/bin/st-util: not in executable format...
> I have not tested with st-util. But as it offers an gdb server it
> fine. But you have to start the st-util backend alongside qtcreator
> yourself. The host and port describe the port of the debugger.
> The command window lets you enter the custom hw debugger monitor
> to load the code into the device and reset the pc to the start
> If its not working, you should post the debugger log output from the
> log output window.
> Best regards
> Qt-creator mailing list
> Qt-creator at qt-project.org
More information about the Qt-creator