topic Re: TBLCF open source debugging cable in ColdFire/68K Microcontrollers and Processors

TBLCF open source debugging cable

DanielM — Mon, 21 Aug 2006 15:48:33 GMT

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

Re: TBLCF open source debugging cable

alsuren — Wed, 23 Aug 2006 17:39:07 GMT

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.

Re: TBLCF open source debugging cable

DanielM — Thu, 24 Aug 2006 13:42:02 GMT

Hi,

that is a very good question to which I do not have a good answer. I have never tried to even use GDB and I have absolutely no idea how it works on the inside. I am making the interface required to talk to my cable open. It would take someone with the knowledge of GDB to implement a module which would fit between GDB and TBLCF.

There must be people out there with the knowledge of GDB, but unfortunatelly I am not one of them.

Thanks for the offer in terms of packages - I am happy with just a bare PCB to sit on my desk, but other people might be more picky about this. If somebody somewhere decides to manufacture this cable and sell it for a little profit, then a box would possibly be a good idea... Can you tell me more about what you have in mind? Any idea about how much it would cost?.

Daniel

Message Edited by DanielM on 2006-08-24 01:48 AM

Re: TBLCF open source debugging cable

alsuren — Thu, 24 Aug 2006 19:37:39 GMT

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.

Re: TBLCF open source debugging cable

DanielM — Thu, 24 Aug 2006 22:36:22 GMT

Oh, I see - I misunderstood.

What OS are you using? Windows, Linux or something else? I am forced by circumstances to use Windows and I cannot develop for any other OS at the moment. If you are using GDB under Windows and the dBUG support is a clearly module in GDB then I might be tempted to get involved and convert that into a module which would support USB and TBLCF.

Daniel

Re: TBLCF open source debugging cable

alsuren — Thu, 24 Aug 2006 23:36:19 GMT

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.

Re: TBLCF open source debugging cable

wste — Tue, 05 Sep 2006 21:15:14 GMT

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...

Re: TBLCF open source debugging cable

alsuren — Tue, 05 Sep 2006 22:18:06 GMT

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.

Re: TBLCF open source debugging cable

wste — Wed, 06 Sep 2006 13:17:16 GMT

Hello,

sorry, if I may sound stupid, but I seem to have missed something.
Why do I need P&E software? Is it required for the USB BDM interface?
The 64K starter edition of what?

I would like to try your toolchain. I am using eclipse myself already, both, on windows and linux. I use the CDT in combination with my own makefiles, though.
I could not find your email address in your profile.

Thanks for your help,

-wolfi

Re: TBLCF open source debugging cable

alsuren — Thu, 07 Sep 2006 07:17:52 GMT

Sorry. I was slightly off topic: What I was saying is that I have an example project that shows off eclipse's managed make, but it's based on example project code provided by P&E. Has nothing to do with the debugger, but I don't know what the rights are to the code samples they give, so I don't want to link the download to people who don't already have the code.

My email address for this forum is alsuren@gmail.com. Probably should have provided it with the original comment, but I couldn't remember whether I had included it in my contact details or not. Hopefully, I will get a reply from P&E soon, so that I don't have to go through all this silliness, and I can post a link straight on the boards. Sorry for the inconvenience until then.

Re: TBLCF jb16_boot.cat

oloft — Wed, 27 Sep 2006 16:15:49 GMT

According to the jb16_boot.inf there should be a file named jb16_boot.cat.

Is that file missing from the distribution?

Message Edited by oloft on 2006-09-2704:16 AM

Message Edited by Alban on 2006-09-27 03:16 PM

Re: TBLCF jb16_boot.cat

DanielM — Fri, 13 Oct 2006 18:57:37 GMT

Hi,

well, it is not missing really as it would be empty anyway (the driver is not certified by Microsoft). If you need the file, just copy the tblcf.cat and rename it.

Daniel

Re: TBLCF open source debugging cable

Daest — Thu, 19 Oct 2006 12:57:14 GMT

Hi DanielM,
I just assembled my first tblcf board. Everything works fine, I mean, debugging is possible. Is there any possibility to speed up the GDI Interface? In comparison to Pemicro interfaces, tblcf dwonload speed is similar to P&E Cable_CFLV. A Cyclone Max connected to USB is 10 times faster. Wouldn't it be great to reach this datarates?

Steffen

Re: TBLCF open source debugging cable

DanielM — Thu, 19 Oct 2006 16:38:42 GMT

Hi,

the speed problem is not matter of the GDI interface of the debugger. The problem is in in two things:

1) The HC08 is not fast enough
2) The low speed USB interface implemented on the HC08 limits the bandwidth of the USB interface

In another words we could gain speed by:

1) talking to the ColdFire faster over the JTAG/BDM interface using a faster micro
2) by transfering the data faster between TBLCF and the PC

You could use a faster microprocessor for the interface with 12 Mbit/s USB and then it would be no problem to achieve speeds similar or above those of the Cyclone interface.

However the main goal of this project was to offer a simple and inexpensive solution. If you use a faster micro it is probable that you would have to use a double-sided PCB which is difficult to etch in your garden shed. The micro will also cost you more and if you use something like the S12UF32 you will have to build the TBDML cable first to be able to program the firmware in...

This interface should be a reasonable starting point for people who do not want to spend too much money when they want to try coldfire for the first time. If they later start doing some serious stuff and they need a faster interface, then maybe that would be a good time to buy the cyclone.

I belive that P&E should not be selling an interface for $250 when you can build one of similar performance for $10 - that is a disgrace. That is one of the reasons why I started this project in the first place.

Daniel

Re: TBLCF open source debugging cable

Daest — Fri, 03 Nov 2006 20:47:57 GMT

Hi DanielM,
is it possible to use CFFlasher with a TBLCF programmer?
For this reason, a BDM communication interface dll is needed. With USB COLDFIRE MULTILINK or CABLE_CFLV, these dll's are distributed by pemicro. Do you know anything about this Interface?

Steffen

Re: TBLCF open source debugging cable

DanielM — Sun, 05 Nov 2006 07:25:06 GMT

Hi,

no unfortunatelly I do not know anything about this interface. I have never tried to use TBLCF with CFFlasher and I doubt it will work.

If there are any details available I might create the dll, but I have not created anything for CFFlasher so far.

Sorry.

Daniel

Message Edited by DanielM on 2006-11-10 08:29 AM

Re: TBLCF open source debugging cable

w_wegner — Fri, 10 Nov 2006 23:54:10 GMT

Hi Daniel,

thank you very much for providing this TBLCF project!

I just built my first TBLCF, and it is recognized on the USB without any problem. However, when trying to program it, I get the message:

D:\Eingang\tblcf_v10\pc_binaries_v10>tblcf_bt -B tblcf.abs.s19
Turbo BDM Light ColdFire Bootloader ver 1.0. Compiled on May 23 2006, 08:33:37.
S-rec: "D:\Documents\projects\bdm_cf\sw.jb16\tblcf_firmware\bin\tblcf.abs"
found 2 busses
found 1 HC08JB16 ICP device(s)
Boot sector contents different, performing mass erase
Mass erase done, programming boot sector
USB communication problem or programming failure

I am also wondering what the path "D:\Documents..." does, but to be sure I placed a copy of tblcf.abs.s19 at the location printed there.

Can you give any hint what might be wrong?

Thank you,
Wolfgang

Re: TBLCF open source debugging cable

w_wegner — Sat, 11 Nov 2006 00:48:04 GMT

*sigh*
to answer my own question:
it was a broken board. It seems R4 was not correctly soldered (&%${}"$ leadless solder...).

I first soldered a second board and this one is programmed flawlessly, then re-worked the first board part by part until it could be programmed, too.

Sorry for bothering!
Wolfgang

Re: TBLCF open source debugging cable

DanielM — Sat, 11 Nov 2006 00:57:14 GMT

Wolfgang,

great to hear you got it working. The thing the tool prints is the S0 record from the S19 file. CodeWarrior places the full path of the project into the S0 record, i.e. it is the path to the file on MY machine when I compiled the firmware...

Daniel

Re: TBLCF open source debugging cable

w_wegner — Wed, 29 Nov 2006 01:20:41 GMT

Hi Daniel and all,

after these first problems I have had partly success with TBLCF in m68k-bdm-tools.

Right now I am trying to get the complete gnu toolchain and especially gdb working, so I am not sure yet if this works. bdm-chk looks promising (under cygwin), but I think the code is not really ready for public release.

In case anybody is interested, please send me an email to wolfgang@leila.ping.de so I can provide the sourcecode or patches.

Regards,
Wolfgang