User forums > Embedded development

Cross debugging problem using Uniwin

(1/3) > >>

oliver69:
Hi,

I am using CodeBlocks together with Uniwin to build and debug an application for a TI DaVinci Board.
Code editing, compiling and linking is working fine, except that i cannot use CodeBlocks as a frontend for debugging.
Using Uniwin's proxy gdb.exe directly from the command line on my Windows PC works fine.

My setup is based on the description in:
http://wiki.codeblocks.org/index.php?title=Installing_Uniwin_remote_compiler
I think my problem is not new and has already been solved because exactly the same problem is mentioned in the last paragraph "Troubleshooting" of this wiki article. The Problem is that the bug fixed Uniwin proxy gdb.exe from the referred forum article has been deleted by the admin (http://forums.codeblocks.org/index.php/topic,4516.15.html).

Can this patched version of Uniwin's gdb downloaded from anywhere else?
Is there an other workaround?

Maybe there is another reason for my problem, so please let me provide more details:
Actually, what i am trying to do is: Cross debugging the TI board using gdbserver from a Linux machine (with the Linux cross toolchain) and tunneling the commands with Uniwin so that i can control this from my Windows machine using CodeBlocks.
I have verified that the cross GDB integration in Codeblocks works in principle (tried it with a self compiled Windows native cross debug version of gdb for ARM, but this had other problems...). The "only" problem is with Uniwin's gdb.
* CodeBlocks Nightly Build: SVN 5716 (July 21 2009)
* Uniwin: uniwin.0.5b.binary.02_26_2006
* Development PC: Win XP
* CrossCompileToolchain: Montavista 5.0 (on SuSE Linux)
* Target: TMS320DM6467 EVM Board
* Toolchain prefix: arm_v5t_le-
* Some of Uniwin's executables (gcc, ar gdb) on my Windows machine have been renamed for also using the prefix, because otherwise the wrong programs are called on the CrossCompiling Linux machine. This is proposed in the Uniwin manual and works fine with the compiler and linker. But not with the Debugger.
* The PATH has Uniwin's bin directory as its first entry, in front of all other compilers/debuggers.

I can provide more details, if this is necessary.

I would greatly appreciate any help on this problem.
Many thanks in advance.

Oliver







MortenMacFly:

--- Quote from: oliver69 on October 08, 2009, 12:57:46 pm ---Can this patched version of Uniwin's gdb downloaded from anywhere else?

--- End quote ---
Here it is (see attachament).

Probably Yiannis could provide the sources, too. That'd be most convenient.

[attachment deleted by admin]

oliver69:
Hi Morten,

>Here it is (see attachament).
I have just tried it, works perfectly.
Thank you very much for your quick help!

>Probably Yiannis could provide the sources, too. That'd be most convenient.
It really would be, although it looks like i don't need them anymore ;-)


Yours sincerely
Oliver

zanget:
hi,oliver69

I'm going to ask about compiling a cross compiler on win for the embedded system.
Is it possible by using CB here and then debug on the embedded system?


I want to compiling m68k-elf-tools on win so i can compiling  a app on win  running on embedded system by CB。
thanks

MortenMacFly:

--- Quote from: zanget on January 05, 2010, 02:55:23 am ---I want to compiling m68k-elf-tools on win so i can compiling  a app on win  running on embedded system by CB。

--- End quote ---
Setting up a C::B project to compile the compiler seems not very logical to me. If you want to compile a cross compiler you usually should use the suggested environment which is usually automake / Makefile based or alike. Ask the compiler's devs for help accordingly.

However, once you've compiled your cross compiler and it's really working you can embed this into C::B. This is possible in several ways:
1.) Use an existing compiler if your compiler is command-line compatible
2.) Use a copy of an existing compiler if you need to tune parameters / the setup in general
3.) Extend the compiler plugin by your cross compiler. This is easier as you might think, but requires you to compile C::B itself, too (which is also easy).

Navigation

[0] Message Index

[#] Next page

Go to full version