|
|
|
|
|
Freescale Forums :
Freescale Product Forums :
68K/ColdFire® MPU :
TBLCF open source debugging cable
|
|
| Jump to Page:
1
·
·
·
·
·
·
·
·
·
| Next Page
|
|
|
|
|
TBLCF open source debugging cable
[ Edited ]
|
|
DanielM 
VIP
Posts: 77
Registered: 2006-06-29
Message 1 of 102
Viewed 31,455 times
|
|
Hello everybody,
for the benefit of the ColdFire users community I am releasing an open-source debugging cable. The cable works with CodeWarrior version 6.3. You can download evaluation version of CodeWarrior 6.3 here:
https://www.freescale.com/lgfiles/updates/CWCF/CW_ColdFire_6.3_Update.exe
Cost of components for the cable is under $10.
Feedback on functionality and/or any problems is most welcome.
I will be updating this post with new releases in case of bug fixes or other improvements.
I have added a zip file with the PCB design in EPS and BMP formats.
Daniel Message Edited by DanielM on 2006-10-13 11:03 AM tblcf_v10.zip eps_and_bmp_v2B.zip Message Edited by t.dowe on 2009-09-02 04:58 PM
|
|
|
|
2006-08-21 09:48 AM
|
|
|
|
|
Re: TBLCF open source debugging cable
|
|
alsuren
Contributor
Posts: 12
Registered: 2006-07-11
Message 2 of 102
Viewed 31,351 times
|
|
|
Looks cool!
How easy do you think it would be use it with GDB (GNU DeBugger)? It would be interetsing to have an entirely open source development platform based on this thing. I'm thinking "Eclipse, CDT, [mingw|cygwin + m68k-elf-gcc] GDB, TBLCF"
Then, the only thing you don't have the source for is the coldfire itself... and the Sun JRE for eclipse, but there are OSS JREs floating about if you're a purist.
If you want a hand with packaging, I *may* be able to provide.
|
|
|
|
2006-08-23 11:39 AM
|
|
|
|
|
|
|
Re: TBLCF open source debugging cable
|
|
alsuren
Contributor
Posts: 12
Registered: 2006-07-11
Message 4 of 102
Viewed 31,283 times
|
|
By packaging, I was thinking more the software stack. IMO, your board looks nicer than the P&E MultiLink package, which just feels cheap, and rattles when you shake it.
My employer *may* be shipping your debugger with a few of his graphics (or motor control) development boards. This is providing I (or anyone) can write something that will interface nicely with either gdb, or plain eclipse (for the purposes of debugging, or at least flashing). The current interface is rs232, using gdb with the old motorola dBUG monitor. It works passably well, but *very* slowly. I'll post here when I have something functional, but don't expect anything major until the christmas holidays, and you won't be disappointed.
I don't expect my employer's development boards to be *particularly* affordable, because they're likely to be quite low volume.
Note that I'm only a work experience student, so I will have left the company by the time the boards start shipping, and the initial batch is likely to ship with dBUG, but I'm quite interested in developing an open tool chain, so I will do it in my own time, and then I won't be under pressure to make it impossible to redistribute, like the P&E toolchain, or the Steroid Micros toolchain, which are both based on OSS tools, but rely on closed extensions. (maybe we can get Cambridge University using coldfires rather than ARMs in their computing projects: They seem to favour open tools over closed ones)
The big problem with eclipse at the moment is that its editor doesn't try to understand assembler syntax. I expect that to change in time, because the C development tools get dramatically better with each release. It seems to do everything else very nicely though (including automated make, whenever you modify a file, and context assist) as long as you can get it configured correctly to start off with.
|
|
|
|
2006-08-24 01:37 PM
|
|
|
|
|
|
|
Re: TBLCF open source debugging cable
|
|
alsuren
Contributor
Posts: 12
Registered: 2006-07-11
Message 6 of 102
Viewed 31,260 times
|
|
At work, I'm on Windows (2000, the height of Microsoft's operating system line). GDB compiles under mingw with dBUG support if you configure it with --target=m68k-dbug-elf (might want to try compiling under cygwin if it doesn't work, but cygwin is *painfully* slow).
GCC, on the other hand, has *major* problems with cygwin/mingw, so I've been using the pre-compiled mingw binaries from P&E (you can download them for free, in the "starter" development kit, but they come packaged with a crippleware BDM debugger/flasher, code limited to 64k, and a version of newlib that may or may not be modified, so redistributing their binaries is not something I'm prepared to risk) This is just until I can get something compiled myself, of course. Running their binaries with the -v option gives some interesting insights into how they were cross-compiled.
--no need to read below this line, as it has little to do with GDB--
At present, I'm stuck at home on linux, with a cold, so I can't give details about my windows system, but the eventual aim is to distribute a mingw system in a zip file that contains the full source code to gcc, newlib and gdb, and a set of scripts which will reliably compile those tools (so you can edit them if you want), plus pre-compiled binaries as a fall-back for the lazy among us, and a pre-compiled version of eclipse, with example projects (probably based loosely on the public domain dBUG code) which are automatically built by the eclipse Managed Make tool, even when you add new C source files. It will then be up to the community to add support headers etc. for the memory mapped peripherals on different coldfires.
The other possible path is a set of scripts and binaries for use on an x86 system (probably [k]ubuntu dapper, because it's easier to install for new users) with *known* versions of compilers etc. which will perform the same mystical feats. This is likely to be easier to develop for me, and more useful, because I don't have a version of windows lying around at uni, but my sense of ego wants to see this project go cross-platform.
Ambitious? Possibly. Maybe it's the cold talking.
|
|
|
|
2006-08-24 05:36 PM
|
|
|
|
|
Re: TBLCF open source debugging cable
|
|
wste
Visitor
Posts: 6
Registered: 2006-09-05
Message 7 of 102
Viewed 30,830 times
|
|
I recently built a cygwin based gcc cross tool chain for m68k, using quite actual versions of the tools: binutils 2.17 (+CPU32 patch), gcc 3.4.6 and 4.1.1, bdm tools from sf.net/projects/bdm/ (CVS release + Coldfire 2/2M patches by Christian Walter) for the P&E parallel-port BDM interface that shipped with my M5235BCC eval board. With these tools, I am able to build a very basic app, download it and single-step on the target.
What gcc related problems are you referring to? The build went quite smooth for me, albeit the cygwin build takes ages to complete, under Linux, the same toolchain was built in about one quater to one fifth of the time.
I would like to try the USB BDM interface and even potentially invest some free time to interface it with the BDM work at sourceforge. But unfortunately I am not in the position to build that interface myself...
As for gdb, I had to use the old (2003) 6.0 version, because for 6.5, the register mapping stuff was changed completely and I don't know enough about the Coldfire family and gdb internals to integrate that correclty, alas! I'll be posting on that subject to the bdm-devel list soon. I feel, Freescale could really help out in that project! Would be a great move of them.
PS: I didn't know, gdb supports dBUG! Shame on me I missed that...
Have to try that...
|
|
|
|
2006-09-05 03:15 PM
|
|
|
|
|
Re: TBLCF open source debugging cable
|
|
alsuren
Contributor
Posts: 12
Registered: 2006-07-11
Message 8 of 102
Viewed 30,823 times
|
|
Alright: I have made a zip file of my mingw/gcc/eclipse install, with an example project that will compile for coldfire. It's a bit huge, and it also contains some example code which may or may not have a restrictive copyright on it. I am in the process of contacting P&E to ask what the terms of distribution are, but for now, please get the "64K Starter Edition" from the P&E website (might require registration) and then email me asking for a link. That way, I can't be accused of giving you anything you don't already have.
At present, it doesn't include an m68k-elf-dbug version of GDB, because I've not had an opportunity to test it, but if anyone wishes to add support for dBUG/BDM+gdb, and can guarantee that they're not breaking any laws in the process, I might be able to host it for you.
As I say: if you're interested, email me.
|
|
|
|
2006-09-05 04:18 PM
|
|
|
|
|
|
| Jump to Page:
1
·
·
·
·
·
·
·
·
·
| Next Page
|
|
|
|
|
