TBDML debugging interface for HC12, S12, S12X and S12XE microcontrollers

[DanielM]

TBDML is a low cost, open source debugging interface compatible with the CodeWarrior environment (version 4.1 or greater).

This project was previously published on freegeeks.net. Since the freegeeks site has now been shut down I am posting the latest version of the project here for the benefit of anyone interested.

When older HC12 MCU derivative was selected from the menu the debugger did not remember the choice when started again. GDI DLL version 1.8 in distribution 1.2F fixes this. There is no other change compared to distribution 1.2E.

Daniel

Message Edited by DanielM on 2006-11-06 11:15 AM

Message Edited by DanielM on 2006-11-06 11:18 AM

distribution_12f.zip

Message Edited by t.dowe on 2009-09-01 10:57 AM

[luanda07]

hey, can your project program the target?

[DanielM]

of course it can program flash of the micro - RTFM.

Daniel

[luanda07]

hey Daniel, I think that I dont explain my question.

Can you program the user software into MCU HCS12 with TBDML?

If you can, how do you do if you haven´t a VFP (voltage flash program, 12V)? Because the HCs12 need a VFP.

hugs

[imajeff]

luanda07,

I think you need to read more docs than just TBDML. You would notice that 9S12 (I assume you mean since there is no such thing as HCs12) does provide internal VFP. Also I assume that if you are programming HC12, since it does need external VFP (12.0 V), then the developer would know that and provide one as my Adapt912 does have one. It need not be part of the BDM.

[rhinoceroshead]

Imajeff,

Why do you insist that people call it 9S12 and claim there is no such thing as HCS12?

Even Freescale uses the general term 'HCS12'.  Click on 'Products' and look under the 16-bit Microcontroller category.

I've naively assumed that the extra S was there to indicate that the device was made using a silicon process that allows for higher speed, but it is still CMOS.  I also assumed that Freescale dropped the 68HC from the part numbers only in the interest of abbreviation.

I don't really care - I've just noticed more than once that you are telling people that they're erroneously calling it HCS12 and I'm wondering why it's bad to call it that.

[imajeff]

---

rhinoceroshead wrote:

Imajeff,

Why do you insist that people call it 9S12 and claim there is no such thing as HCS12?

Even Freescale uses the general term 'HCS12'. Click on 'Products' and look under the 16-bit Microcontroller category.

---

Yes, I'm glad you asked, because obviously even Freescale does not care. Sure, Before I insisted, I knew that insisting would change nothing. And sure, I've already explained it, but maybe not here(?) The problem is still getting worse with all the twisted runoffs. And beleeeeve me when I say Freescale is adding to the problem.

It all starts with a simple computer program. When a computer is comparing strings, could you tell it to search for "HCS12" and have it find the "MC9S12XDP512"? Not hardly. But then again, why should I search for "HCS12" if there is NOT ONE SINGLE PART NUMBER with that sequence of characters in it??

Scenario:

When I google for HCS12 stuff, I only get a small fraction of hits. I start getting creative and find many different ways people name it on their websites. Now I'd have to go to colledge and study an advanced querry language in order to combine all the possibilities just to get that one complete list that I wanted. I would also have to guess all of the ways people are spelling it. No I was not complaining only about trying to make "HCS12" an alias MCU name. It just boggles my mind that there are more aliases, or mis-namings (for example classifying it under 8051).

I can't just go through one possible search at a time because websites are getting "smart" and using all of the possible ways that they know to say 9S12. So I would keep finding the same websites (but still not all of them) each time I searched for a new way to spell it.

[imajeff]

rhinoceroshead,

I finally looked way back to my post you referred to. If you read what I was replying to, you will see that I was not only talking about my saga of searching for all possible "alias" for the 9S12 families.

I was merely pointing out that I could not help the poor guy very easily because he gave no part number, but was confused in stating that the "HCs12" requres VFP. I know that the HC12 family does (e.g. my XC68HC912BC32), but not any of the S12 I know of.

But I still insist that "MC9S12C32CFU" contains no "HC".

[rhinoceroshead]

I understand.  I can relate to your frustration.  My interest in the HC12 started with a college course that I took with a book titled "68HC12 Microcontroller".  When I looked for more information online I couldn't find much until I searched for MC68HC912B32 or MC68HC812A4.  But now I just consider HCS12 to just be a general classification term and it doesn't really bug me.

[Nabla69]

Hi Rhino,

The difference between the HC12 family and HCS12 or S12 is a different technology size.

HC12 are in 0.5µm

S12 are in 0.25µm

S12XD are 0.25µm and the brand new S12XE is 0.18µm.

The 9 means Flash, as the 7 would mean OTP and the 3 means ROM.

For instance, the MC3S12RG128 is the ROM equivalent of the Flash MC9S12DG128.

Now, part numbers of the S12 dropped the HC part to become MC9S12DT256 for instance. Instead of the long and redundant MC68HC9S12DT256.

MC means it is fully qualified.

PC means prototype,

XC is obselete now.

That's why you could call them S12 as much as HCS12.

Cheers,

Alvin.

[eckhard]

Hello,

could you please tell us what is new in distribution12. I use the JB16 version of TBDML. Is the software running on the JB16 too or has only the windows part changed ?

Eckhard

[DanielM]

Hi,

the changes are documented in the readme file, but here you go:

Changes:

v11d: added tbdml.exp and tbdml.lib to bin_tbdml_dll_11.zip
added missing tbdml_hwdesc.h into sw_tbdml_dll_11.zip
added the 00readme.txt for better orientation

v11e: C9 and C12 did not agree between schematic and PCB in the doc. Changed the schematic.

v11f: Behaviour of the debugger was not correct during external target reset.
New DLL for Hi-wave and new firmware for the cable generated.

v11g: Added CPU selection menu for old HC12 devices

v12: Changed reported features in the GDI DLL to tell the debugger to use SW breakpoints when possible (i.e. when debugging from RAM)

I.e. no changes to the firmware, still version 0.3. The latest change is in the GDI DLL for the debugger.

Daniel

[eckhard]

Hello,

now I found it. Just had to scroll down a bit.

shame on me.

Eckhard