Proprietary DEVBOARD

Sysprogs forums Forums VisualGDB Proprietary DEVBOARD

Viewing 9 posts - 1 through 9 (of 9 total)
  • Author
    Posts
  • #9844
    hfrmobile
    Participant

    I am new to VisualGDB (currently evaluating it for our project). I tested it with a simple Linux app (Ubuntu on a virtual machine) and everything works fine with that.

    But I am confronted with following  situation:

    1. Target hardware: i.MX28 CPU, USB, TFT display, LAN, … running Embedded Linux
    2. “Customized toolchain” designed to run on a Unix machine, so I setup a Ubuntu virtual machine
    3. Need a working development environment under Windows 10 (that’s why I landed on VisualGDB)

    So, the Ubuntu box is simply a build/debug host for me.

    I am able to establish a SSH connection to target device and everything works so far as long I use the Ubuntu development envirnonment (Eclipse Luna). The “toolchain” contains lot of bash scripts for doing stuff like compiling, starting the Eclipse IDE.

    But I like to use Visual Studio and VisualGDB as my primary development environment.

    I learned that I can’t use the “Embedded Project Wizard” since it offers templates for lot of boards, but our board is not listed of course, since it is handmade by our hardware vendor. So I have to do the “Custom Project Wizard”.

    Deploying the sources from Windows to the Ubuntu machine is easy:

    Custom Build Steps / “Before Building”

    • “Send files to remote computer” (sources, scripts, …) – OK
    • “Run a custom command line” (“. INIT.sh”) – OK (initialized the “hand-made-properitary toolchain by hardware vendor”)

    But now I want to start the build on the Ubuntu machine:

    Build Settings / “Build Command”: But VisualGDB only offers me to specify local/Windows .exe file here – but the build should be done on the remove (Ubuntu) machine …. (BTW: Can’t install the “hand-made-properitary toolchain by hardware vendor” since it contains header files (.h) which differ only by lower/upper case; and I am sure there are other things which won’t work under Windows – That is why I chosen VisualGDB)

    Do I miss something? Of course I may call “make” at the “Custom Build Steps / Before Building” but VisualGDB will always give me the warning that no Build Command is set. So the correct way seems to be at “Build Settings / Build Command” ….

    Would by very kind putting me to the right direction.

    Btw, found this tutorial but it seems to be for an older version of VisualGDB (currently using 5.2):
    http://visualgdb.com/tutorials/digi/

    There, the call also “make” in a “Custom action” on the remote Linux machine …

    Exists there a tutorial which demonstrates the “Custom Project Wizard” for VisualGDB 5.2?

    Kind regards,
    hfrmobile

     

    #9875
    support
    Keymaster

    Hi,

    Sorry for the delayed reply.

    The Digi tutorial is very old and does not reflect the new simplified project wizards.

    Most likely you don’t need to use the Custom wizard at all – if your toolchain consists of the regular tools like gcc, ld and make, you can simply select it in the VisualGDB project wizard and VisualGDB will setup a basic project automatically including the necessary deployment steps (see this tutorial: http://visualgdb.com/tutorials/linux/3machine/).

    If you want to configure manual build steps nonetheless, you can change the build machine (where gcc and other tools are located) globally on the Project Settings page.

    If you encounter any further problems, please feel free to let us know and we will help.

     

    #9885
    hfrmobile
    Participant

    Thanks, looks good! I’ll give it a try!

    Since trial period expired today/now I am waiting for the license arrival … 🙂

     

    #9887
    hfrmobile
    Participant

    License received 🙂

    Did the tutorial as suggested. I am a bit confused. Why Linux project and not “Linux embedded”? I am quite new to the Linux world and I thought that the (executable) binaries on desktop (e.g. Ubuntu) differ from the Embedded Linux? (my idea: .elf (executable file format)  is for embedded?). If this is wrong, why there are different Wizards for “Linux” and “Embedded” projects?

    The deployment works so far (finding the executable binary on the Linux Embedded board) but debugging fails.

    -rwxr--r--    1 root     root        398968 Dec 29  2016 pw2clb

    My project differs from the tutorial since I like to use Qt, so I’ve chosen “Qt4” when the Wizard asked me.

    GDB log:

    Thank you for your purchase. Your license details will be loaded and shown in the next 24-48 hours.
    f4: gdbserver exited with code 1
    at gh1.b1()
    at gh1.c_2(DebugCustomizationSettings a)
    at uf1.v1()
    at VisualGDB.GDBDebugEngine.j1(g01 b, f a)

     

    GDBServer log:

    Process /tmp/pw2clb created; pid = 723
    Cannot exec /tmp/pw2clb: Exec format error.
    Child exited with status 127
    No program to debug.  GDBserver exiting.

    Found another thread with a similar problem but without solution.

    As the log says “Exec format error” is the problem in my case ….

     

    • This reply was modified 7 years, 10 months ago by hfrmobile.
    #9889
    hfrmobile
    Participant

    additional info: the built binary/executable works on the Linux Desktop (build host) machine but can’t execute/debug it on the target (board).

    #9896
    support
    Keymaster

    Hi,

    Sorry for the confusion. In VisualGDB terminology, Embedded projects are the ones without any OS (i.e. barebone) that run on hardware like STM32. Linux projects involve the same setup/build steps for both Desktop and Embedded Linux, so they use the same Linux project wizard.

    The “Exec format error” error means that your binary is not compatible with the target machine. E.g. you could have selected the normal x86 Linux toolchain instead of the ARM one or are trying to deploy the ARM binary on a Desktop machine instead.

    Please double-check the selected toolchain and the target machine in your VisualGDB Project Properties.

    #9901
    hfrmobile
    Participant

    Okay, that explains a lot 😉

    “Exec format error”: Yes, but the “GDB Session failed to start” says:

    ~”This GDB was configured as \”–host=i686-pc-linux-gnu –target=arm-buildroot-linux-gnueabi\”.\nType \”show configuration\” for configuration details.”

    So on the build server (virtual Ubuntu machine is x86 and the binary can be executed and works – displaying Window with a button on it – when clicking the button displaying a message box). But I don’t know how to launch the binary on the Linux Embedded device.

    Used the Wizard as suggested but selected Qt4 since I have to use Qt. The board has a display attached. A small demo project already runs on the board displaying a white screen with a button on it.

    Just tried the “C++ Hello world” (so exactly the same as in the tutorial) and this works!
    So it seems that Qt4 causes the problem …. (used the same custom Toolchain)

     

    • This reply was modified 7 years, 10 months ago by hfrmobile.
    #9904
    support
    Keymaster

    Hi,

    If the program runs successfully on the build server (x86 machine), this is an x86 executable and it won’t run on ARM.

    In order to build Qt applications with a cross-toolchain, you need to get a special cross-compiled build of Qt (including a special version of Qmake) and specify it when creating the VisualGDB project. This is fairly complex, but we have detailed instructions on doing that with a Windows cross-compiler: http://visualgdb.com/tutorials/raspberry/qt/embedded/

    We also offer a service of building custom toolchains, so we could build you a Windows toolchain with a cross-built Qt that will be 100% compatible with your target board if you don’t want to do this yourself. Simply contact our sales to get a quote on that.

    #9941
    hfrmobile
    Participant

    Hi,

    thank you for your help! Since we already have a “special cross-compiled build of Qt” (provided by our hardware manufacturer) I simply needed to provide the path to the correct qmake version.

    Thank you for the offer anyway!

    Everything now works as expected. 🙂

     

Viewing 9 posts - 1 through 9 (of 9 total)
  • You must be logged in to reply to this topic.