TBLCF open source debugging cable

[DanielM]

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

[jsmaia]

Hi All,
Sorry for this so newbe question. Do this device may be used for program and/or debug the PCF51QE128CLH? I've just received some samples and don't know how to start to use it.
Sorry for my poor English.
Thank you.
Maia

[Radiofid]

Hello.

I have assembled your version of cable. It works, but I have a problem. I know that your cable isn't working with CFFlasher, cause it needs some DLL for it. So, I tried to wrote program with CFFlasher functionality, that works with TBLCF. I tried to get functions from tblcf.dll. Functions tblcf_dll_version and tblcf_init work perfectly. But when i try to use function tblcf_open there an error occures - access violation in module libusb0.dll.

I tried to recompile your dll with LCC (if i understood properly, you have use this compiler), but linker found errors:
tblcf_usb.obj .text: undefined reference to '_usb_init'
tblcf_usb.obj .text: undefined reference to '_usb_set_debug'
tblcf_usb.obj .text: undefined reference to '_usb_get_version'
tblcf_usb.obj .text: undefined reference to '_usb_find_busses'
and so on...

Do you have any ideas what I should do to make tblcf.dll work properly, or to recompile dll?

I will try to rewrite functions on Borland C++ Builder, but may be you have any new version of DLL or something else? Thanks in advance!

Valery.

[w_wegner]

Hi,

I am not familiar with LCC and all these, but the symbols you mention belong to lilbusb. You should include this library (or DLL) into your project, then all should be fine.

HTH,
Wolfgang

[gxd]

Hi:  Daniel, I just asm my TBLCF. and before connect my target , all seem right.

(down, programmed and PC can detect my TBLCF  according to your manual, set GDI etc). my develop tool is CW6.3 down from FREESCALE. OS is windows XP.

but when I hit debug(CODEWARRIOR IDE5.7.0), I got the error "Exception vector name: Address Error" when I tried to debug the program(when I entry again, this message not appear). Then example_flash window appear.Source windows is :

(mcf52235_lo.s)

asm_startmeup:
_asm_startmeup:

    /* Save off reset values of D0 and D1 */
>>>    move.l  d0,d6
    move.l  d1,d7
   
    /* Initialize RAMBAR1: locate SRAM and validate it */
 move.l #__SRAM,d0
    add.l   #0x21,d0
    movec   d0,RAMBAR1
.....

I  find the LED on TBLCF flashing about two every second. can not  run ,step....

another problem see  manual page17,

" Enter path to a configuration file in case you need to pass start-up options to the GDI DLL (see section 3.3.1 for more details)."   ------ I dont find the .cfg file. so I let it empty. 

Whether i must  used CFLASH TOOLS to program my flash on chip.

when I enter debug, flash on chip MCF52233 will be programmed?

I am sorry,  a new come hope your guidance in dark.

Message Edited by gxd on 2007-07-12 06:31 AM

[gxd]

for error set the cpu .xml file.

by select mcf52230_25MHZ.xml.All thing is ok.

 you do a lot work for fancier.

this proved your work successful.

[threepointone]

Daniel,

This is amazing! I've been scouring the Internet for the past two days for a reasonably priced BDM cable for a project that really was best suited for the coldfire platform, and I've finally found it here! The only other DIY BDM cable required CPLDs, which I've never worked with before and which I don't have the resources to program. Additionally your design uses a USB port--a definite plus, as none of my working computers has a parallel port.

This really opens up opportunities for beginners working with the Coldfire platform--I'm a part time electronics DIYer, part time student and naturally I (and many others in the electronics DIY scene) can't afford to invest that much just to get started. That's why some other microcontrollers have been more popular in the DIY scene--PICs, AVRs, and even ARMs have relatively affordable and simple programming schemes.

Unfortunately, even though this cable design is only a year old, it clearly doesn't have much exposure to be of any real use--as I said, I've been looking for exactly this for almost two days and I found it just now. I'll be spreading the news, and the coldfire platform might just get a bit more popular

Again, thank you very much for your work!!!

Sam

Message Edited by threepointone on 2007-06-26 05:55 AM

Message Edited by threepointone on 2007-06-26 05:55 AM

[Daest]

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

[DanielM]

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

[Daest]

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

[DanielM]

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

[w_wegner]

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

[w_wegner]

*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

[DanielM]

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

[w_wegner]

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

[oloft]

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

[DanielM]

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

[alsuren]

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.

[DanielM]

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

[ovf]

HI, I am also pursuing open source debugging cables for HCS12XE and 68K(CPU32) processors that interface with GDB. I wonder that if we know how "Kevin Ross's" protocol is we could, in principle, adapt cable's firmware from CodeWarrior to GDB. Anyone has "Kevin Ross's" protocol ? Thanks.

[ChrisJohns]

I cannot help with the HCS12XE but the cpu32 is handled with the BDM project on Sourceforge:

 http://bdm.sourceforge.net/

Please ask away if you have problems. The GDB interface is via a gdb-server so GDB is built using no patches and the standard FSF source.

As for Kevin Ross's work I assume you mean:

 http://www.noicedebugger.com/help/bdm12.htm

If you have GPL code to handle the low level the BDM project has code to handle the GDB server side of things. This of course assumes GDB can be built for the HCS12X target. Do you know if it can ?

If you have any questions about the process please ask. I am happy to help if I can.

Regards
Chris

[alsuren]

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.