Forums

M68KIT912DP256

Started by hc12 January 7, 2003
Hello to All:

I thought I'd chime in here with a few words in P&E's defense:

It is true that PCI-based parallel ports are not registered in the bios
and as such do not, by default, appear in the list of parallel ports you
can access. However P&E has written a utility, ADDLPT, which allows you
to specify where additional PCI parallel ports reside. After using this
utility, P&E applications and other third party applications should be
able to see your PCI parallel ports. P&E applications allow up to five
different parallel ports to be selected. This utility is delivered with
many P&E applications, although if you need a copy, please email me
off-list and I will send you a copy. We will also put post this utility
on our website.

It should also be noted that many of our customers, and some of our
developers, use winXP and our BDM tools with no issues whatsoever-- if
you're having problems that you can't seem to iron out, please contact
me offlist and I'll try to work through the issue with you.

Most important, however, please be aware that we are indeed working on
alternate interface BDM pods-- both USB and hopefully Ethernet as well.
These should be available towards the end of Q1 2003-- and obviously
this will eliminate these pesky parallel port issues!

Cheers,
Mark
P&E

wrote:

> It is ridiculous that the P&E Multilink cable still requires a standard
> parallel port. Throw in XP and we have not been able to get our cable to
> work yet It will work under Win 98 but fails under XP even with the
> port
> configured to use interrupts. The other issue I have with a standard
> parallel port is the only one you can have is the one built on your
> mother
> board. Under XP if you install a PCI parallel port you will be unable to
> set it to the standard I/O address for the standard parallel port. This
> is fine if you can dedicate your computer to every development project.
> What if you need more than one BDM cable that requires a standard
> parallel
> port. Then you have to use an A/B switch but if your pod is powered you
> can damage the emulator pod or the computer if you forget to power off
> between changes of port.
>
> Rod Niner
> . >
>
> Bob Furber <>
> 01/09/2003 12:57 PM
> Please respond to 68HC12 > To:
> cc:
> Subject: RE: [68HC12] M68KIT912DP256 > Hi Don,
>
> > From reading these postings, one can get the impression
> > there is only one
> > BDM emulator available for the HC12/HCS12, and it has many
> > problems, and
> > there is nothing to do about it.
>
> Actually, I believe that there are very few problems with
> the P&E debuger and debug cable and and even fewer that
> don't have a simple, inexpensive solutions. We hear about
> these problems because ..well, that is what this list is
> for.
>
> > They don't have any of the reported
> > problems here.
> > Nohau is selling a BDM for $1990, plugging to either USB,
> LPT
> > port or a
> > dedicated ISA card. Other vendors exist as well. Yes, it
> is
> > more expensive
> > than the P&E, but on the other hand it will save some of
> your
> > frustration,
> > and will return its investment by saving the time you mess
> up
> > with problems.
>
> You make some good points. The Nohau emulator may indeed
> offer many advantages over the P&E debugger ..for a price.
> Notwithstanding, many users, including myself, find that the
> P&E debugger/cable offers very good value. Some people drink
> beer, and some can afford champaigne.
>
> It would be interesting to hear about users experiences with
> other debuggers and BDM modules. Maybe us beer drinkers
> should consider coolers, or even champaigne.
>
> Bfn,
>
> Bob Furber
>
> __________________________________________________________
>
> Connect your micro to the internet the easy way
> www.microcommander.com
>
> Microcontroller with an obscenity of I/O & features
> ..in a small footprint www.steroidmicros.com
> __________________________________________________________ >
> -------------------- >
> ">http://docs.yahoo.com/info/terms/ >
> -------------------- >
> ">http://docs.yahoo.com/info/terms/>.




At 10:30 AM 1/12/2003 -0500, you wrote:
>Most important, however, please be aware that we are indeed working on
>alternate interface BDM pods-- both USB and hopefully Ethernet as well.
>These should be available towards the end of Q1 2003-- and obviously
>this will eliminate these pesky parallel port issues!

Mark,

Thanks for the information. Without telling us stuff you aren't
supposed to, can you tell us if there are any plans to upgrade the PROG12Z
and IDE12Z software to better user interfaces, correct some bugs, and
add/fix some features? Maybe a working help file also?

If the HC12 product line is considered a dead end by P&E, it is still a
good value. But it would help us know what to plan for the future.

jmk -----------
James M. Knox
TriSoft ph 512-385-0316
1109-A Shady Lane fax 512-366-4331
Austin, Tx 78721
-----------



James and All:

The HC12 is certainly not considered a dead end by P&E!!! I suppose
what I can say is that we do indeed have plans to release a new version
of our software soon. Let's leave it at that for now!
As for some of your other comments: our current version of the
software should have a working helpfile-- is yours not working? Please
let me know if this is the case, we should be able to take care of that.
We rigorously test ALL our software before release-- however, we
are only human and occasionaly a minor bug may go undetected by our
staff. If you do happen across a bug, I would encourage you to let us
know about it. We will fix them as quickly as possible, and we won't
make you wait for a major release of the software to see the fix in
action!!!

Cheers,
Mark
P&E

-----Original Message-----
From: "James M. Knox" <>
To:
Date: Sun, 12 Jan 2003 12:17:24 -0600
Subject: Re: [68HC12] M68KIT912DP256

> <html><body > <tt>
> At 10:30 AM 1/12/2003 -0500, you wrote:<BR>
> >Most important, however, please be aware that we are indeed
> working on<BR>
> >alternate interface BDM pods-- both USB and hopefully Ethernet as
> well.<BR>
> >These should be available towards the end of Q1 2003-- and
> obviously<BR>
> >this will eliminate these pesky parallel port issues!<BR>
> <BR>
> Mark,<BR>
> <BR>
> Thanks for the information. Without telling
> us stuff you aren't <BR>
> supposed to, can you tell us if there are any plans to upgrade the
> PROG12Z <BR>
> and IDE12Z software to better user interfaces, correct some bugs, and
> <BR>
> add/fix some features? Maybe a working help file also?<BR>
> <BR>
> If the HC12 product line is considered a dead end
> by P&E, it is still a <BR>
> good value. But it would help us know what to plan for the
> future.<BR>
> <BR>
> &nb
> sp;
> &nb
> sp; jmk<BR>
> <BR>
> <BR>
> -----------<BR>
> James M. Knox<BR>
> TriSoft &n
> bsp;
> ; ph 512-385-0316<BR>
> 1109-A Shady
> Lane
> ; fax 512-366-4331<BR>
> Austin, Tx
> 78721 &nbs
> p; <BR>
> -----------<BR>
> <BR>
> </tt>
>
> <br>
>
> <!-- |**|begin egp html banner|**| -->
>
> <table border=0 cellspacing=0 cellpadding=2>
> <tr bgcolor=#FFFFCC>
> <td alignter><font size="-1" color=#003399><b>Yahoo! Groups
> Sponsor</b></font></td>
> </tr>
> <tr bgcolor=#FFFFFF>
> <td alignter widthG0><table border=0 cellpadding=0
> cellspacing=0><tr><td alignter><font face=arial
> size=-2>ADVERTISEMENT</font><br>
> <script language=JavaScript>
> var lrec_target="_top";
> var lrec_URL = new Array();
> lrec_URL[1] =
> "http://rd.yahoo.com/M!9695.2850578.4203976.1925585/D=egroupweb/S=1
> 706554205:HM/id=flashurl/*http://ad.doubleclick.net/clk;5046279;77905
> 48;y?http://www.ameritrade.com/o.cgi?a=cjx&o=roc&p=/offer/25.html";
> var link="javascript:LRECopenWindow(1)";
> var lrec_flashfile =
> 'http://us.a1.yimg.com/us.yimg.com/a/am/ameritrade/120402_am_ban_bc_x
> 37_x_300x250_3.swf?clickTAG='+link+'';
> var lrec_altURL =
> "http://rd.yahoo.com/M!9695.2850578.4203976.1925585/D=egroupweb/S=1
> 706554205:HM/id=altimgurl/*http://ad.doubleclick.net/clk;5046279;7790
> 548;y?http://www.ameritrade.com/o.cgi?a=cjx&o=roc&p=/offer/25.html";
> var lrec_altimg =
> "http://us.a1.yimg.com/us.yimg.com/a/am/ameritrade/120402_am_ban_off_
> x82_x_300x250_6.gif";
> var lrec_width = 300;
> var lrec_height = 250;
> </script>
> <script language=JavaScript
> src=http://us.a1.yimg.com/us.yimg.com/a/1-/jscodes/072002/ct_lrec_072
> 002.js>
> </script>
> <noscript>
> <a
> href="http://rd.yahoo.com/M!9695.2850578.4203976.1925585/D=egroupwe
> b/S06554205:HM/id=noscript/*http://ad.doubleclick.net/clk;5046279;
> 7790548;y?http://www.ameritrade.com/o.cgi?a=cjx&o=roc&p=/offer/25.htm
> l" target=_top><img
> src="http://us.a1.yimg.com/us.yimg.com/a/am/ameritrade/120402_am_ban_
> off_x82_x_300x250_6.gif" width00 height%0 border=0></a>
> </noscript>
> </td></tr></table></td>
> </tr>
> <tr><td><img>
src="http://us.adserver.yahoo.com/l?M!9695.2850578.4203976.1925585/
> D=egroupmail/S=:HM/A00464/randy9845195"></td></tr>
> </table>
>
> <!-- |**|end egp html banner|**| -- > <br>
> <tt>
> --------------------<br>
> ">http://www.motorola.com/mcu</a><br> >
> </tt>
> <br>
>
> <br>
> <tt>">http://docs.yahoo.com/info/terms/">Yahoo! Terms of
> Service</a>.</tt>
> </br>
>
> </body></html>
>


At 09:32 PM 1/12/2003 -0500, you wrote:
> The HC12 is certainly not considered a dead end by P&E!!! I suppose
>what I can say is that we do indeed have plans to release a new version
>of our software soon. Let's leave it at that for now!

Will you promise to let us know when you do? <G>

> As for some of your other comments: our current version of the
>software should have a working helpfile-- is yours not working?

As far as I have been able to tell, there is no online help file for the
current version. We patched the old IDE12W help file to work, but the only
thing I have ever been able to find for the Z version is the HTML help file
at the P&E website. When I was sent the Z version there was no help file
included or, as far as I could tell, available.

> We rigorously test ALL our software before release-- however, we
>are only human and occasionaly a minor bug may go undetected by our
>staff. If you do happen across a bug, I would encourage you to let us
>know about it.

Well, all the documentation on the "recurring interrupt" stack pointer
problem we sent you about four years or so ago would be a good start.
<G> Although I admit that it may be a tuffie, at least some
acknowledgement that it is being worked on would help.

The "slow programming" problem is still open... although we long ago
finished our project. [Has to do with the speed of the host
computer. With some targets (B32) and a SLOW host ('486) everything is
fine. Upgrade to a fast host and it can take several minutes to program
about 8K of flash.

The Windows NT printer port problem was never solved either. We finally
put together a different computer just for the host, so that we could run
with the standard LPT1: port definition.

And of course out latest problem, the hang/crash of the debugger if we
switch memory locations. [Although our e:mails went unanswered, we did
finally find an FAQ which hinted at this problem. So maybe this is a
"feature" rather than a bug. <G>]

Lastly, there is a serious tendency for the BDM pod to latch up in a
high-current mode. If this happens (and it can happen while running,
without warning, and on multiple pods), you have about 10 seconds to kill
power and save the pod -- otherwise the flash memory in the pod is
erased/corrupted. [I have seen this same problem with other B32 chips in
our own designs. The B32 is very sensitive to this.]

>We will fix them as quickly as possible, and we won't
>make you wait for a major release of the software to see the fix in
>action!!!

Let me reiterate that we **have** done a LOT of work with your pods -- some
we purchased for ourselves and some we have purchased on behalf of our
customers. I consider it an good value for the price (with certain
caveats). And I do recognize that P&E is a small company with limited
support staff.

However, it is frustrating to have a recommended method of submitting
problems (e:mail) only to have them continually go into the black hole of
never-never-land. Some fairly cheap suggestions (well, cheap from the
customers standpoint <G>):

1. Assign every problem report a number, and at least acknowledge the
e:mail with that number.

2. Put on the web site a list (preferably searchable) of all these, and a
status number (unverified, verified, not reproducible, work-around, fixed
in xxx). Something like that so that we could not only tell if our own
problems were being worked on, but could also tell if someone else had
identified something we were seeing. [Saves a lot of time if we know that
it is a real problem, and not something with our own equipment.]

3. And please... post on that web site the current version of the software.

See... customers are always willing to find work for the vendor to perform!
<G> And it would be nice (even if for a small upgrade fee) if there were
ever a new version of the IDE software that made it more ergonomic. Some
items there would be:

o Orthographic - i.e. what works in one command should work in
another. Why to I have to type in "EVAL label+offset" and then look at the
results in order to type in "BR nnnn" when I should be able to type in "BR
label+offset". Things like that.

o We have never been able to get the timing measurement feature to work
correctly.

o Have the software look for a LOCAL configuration file first. [Helpful
when more than one project is being worked on from the same host.]

We have more... but again, it *is* a very useful product and I thank you
for developing it.

jmk
-----------
James M. Knox
TriSoft ph 512-385-0316
1109-A Shady Lane fax 512-366-4331
Austin, Tx 78721
-----------





> -----Original Message-----
> From: James M. Knox [mailto:]
> Sent: Monday, January 13, 2003 7:23 AM
> To:
> Subject: Re: [68HC12] M68KIT912DP256

(deletia...)

> However, it is frustrating to have a recommended method of submitting
> problems (e:mail) only to have them continually go into the
> black hole of
> never-never-land. Some fairly cheap suggestions (well, cheap
> from the
> customers standpoint <G>):
>
> 1. Assign every problem report a number, and at least acknowledge the
> e:mail with that number.
>
> 2. Put on the web site a list (preferably searchable) of all
> these, and a
> status number (unverified, verified, not reproducible,
> work-around, fixed
> in xxx). Something like that so that we could not only tell
> if our own
> problems were being worked on, but could also tell if someone
> else had
> identified something we were seeing. [Saves a lot of time if
> we know that
> it is a real problem, and not something with our own equipment.]
>

The GNU Bugzilla bug-tracking system handles this kind of stuff very well.
It might be possible to customize its report so the website can contain a
searchable file of status on each bug. Customers could not only monitor
progress of the bug fixes, but could search for similar problems in other
reports, and perhaps get a work-around or fix faster.
(deletia...)

> We have more... but again, it *is* a very useful product
> and I thank you
> for developing it.
>
> jmk >
> -----------
> James M. Knox
> TriSoft ph 512-385-0316
> 1109-A Shady Lane fax 512-366-4331
> Austin, Tx 78721
> -----------

Karl



At 09:22 AM 1/13/03 -0600, James Knox wrote:
>If [latchup in a high current mode] happens, you have about 10 seconds
>to kill power and save the pod -- otherwise the flash memory in the pod is
>erased/corrupted. [I have seen this same problem with other B32 chips in
>our own designs. The B32 is very sensitive to this.]

Really? Anyone else have experience with this? I haven't noticed it
in the B32 designs here, though I have to admit there have been a few
times when I've needed to reprogram the flash when I was *pretty sure*
I already had the right version of the code burned...

Changing subjects, the thing that bugs me about ICD12, at least the
version I have here, is its tendency to spin and burn 100% of the CPU.
The procedure around here is often to run a testing tool in one window
and ICD12 in another, or sometimes both ICD12 and a terminal window to
D-Bug12. (There's more than one HC12 in this system, so sometimes one
needs two debuggers at once.) The other apps run unbelievably slowly
if ICD12 is active. It's not a fatal flaw, but it is annoying.

Stephen

--
Stephen Trier
Technical Development Lab
Cleveland FES Center / CWRU
/ KG8IH


Hi Michael,

...as I come across your posting I wonder if the "BDM looses
sync..." problem is why I have the problem to debug my same EvalKit
target using the Metrowerks v1.2 IDE on the DP256 controller as if I
choose the:

1) PLL divider/multiplier REFDV=8, SYNR=6 I can halt and break the
code within the debugger, but choosing

2)PLL ... REFDV=1, SYNR=2 for my needed 24MHz ECLK I can't look at
any RAM/Flash symbols within the debugger anymore... and this errata
says that multiplier shouldn't be equal or greater than 2! Is this
the SYNR reg? Than I have a problem 'cause how you can synthesize
24MHz ECLK for a mask 3 (1k79x)with what kind of PLL params???

And this problem is directly coupled to the last "Reading
permanently '0's..." problem I posted several times! I can't look at
if my serial interface output over SCI subsystem on my terminal is
writing the right samples I got or not in my char array out there!!!

Hope that now you better understand my problem dedicated with reading
the port inputs every 1us! Any idea, hint? Hope you can help hereby or telling me some test workaround or
something else to get on... ):

Christian --- In , Mike Burns <mjb@c...> wrote:
> Hi Bruce,
>
> HCS12 parts are supposed to derive the BDM communications clock
directly
> from the crystal so changes in the bus speed via the PLL should
have no
> affect on BDM SYNC. This worked fine in earlier versions of the
DP256 and I
> believe it works fine in all of the other HCS12 parts.
>
> However, MCS912DP256 (and DT256, DJ256, DG256) mask 2 (0K79X) and 3
(1K79X)
> a new problem was introduced (2001) and errata was issued "BDM
LOSES SYNC
> WHEN USING PLL AT HIGH FREQUENCIES"
> http://e-www.motorola.com/brdata/PDFDB/docs/MC9S12DP256BMSE3.pdf
>
> As a result of this errata, both Cosmic and P&E modified their
tools. The
> Cosmic ZAP BDM debugger includes an option for chips with this
errata that
> allows transparent debugging through a PLL bus speed change. The
SYNC
> option has actually been in use for over a year. The
debugger/cable also
> work with the more standard BDM SYNC which is the default out of
reset.
>
>
> Best Regards,
> Michael Burns
> Cosmic Software > -----Original Message-----
> From: Bruce McMillan [mailto:bruce.mcmillan@P...]
> Sent: Thursday, January 09, 2003 10:31 PM
> To:
> Subject: Re: [68HC12] M68KIT912DP256 > John,
> thanks for the survey.
> We also need the debuggers to support the s12 PLL running faster
than
> 8MHz. (Motorola bugs 'n all.)
> cheers. Bruce
>
> John Hartman (NoICE) wrote:
>
> >>Well, there are other BDM emulators for the HC12/HCS12 available
in the
> >>market. And guess what? They don't have any of the reported
problems here.
> >>Nohau is selling a BDM for $1990, plugging to either USB, LPT
port or a
> >>
> >
> > Doron is right. Here are some that have worked well for me
(supported by
> > NoICE), all costing less than ($full featured)/10.
> >
> > Elektronikladen ComPOD12, available from MCT
Elektronikladen GbR
> > (http://www.elektronikladen.de/noicebdm12.html)
> > Technological Arts microBDM12SX, available from
Technological Arts
>
> > (http://www.technologicalarts.com)
> > Kevin Ross BDM12, available from Kevin Ross
> > (http://www.nwlink.com/~kevinro/bdm.html)
> > P&E CABLE12 and MULTILINK, available from P&E
Microcomputer
> Systems
> > (http://pemicro.com)
> > Axiom AX-BDM12, available from Axiom Manufacturing
Company
> > (http://www.axman.com)
> >
> > The first three are serial devices. Slower than parallel port,
but happy
> > with longer cables from the PC, and no driver voodoo or port
compatibility
>
> > issues.
> >
> > The parallel ports ones generally work well, but Billy G. keeps
making it
> > harder to connect widgets to parallel ports, and has decreed the
eventual
> > end of both parallel and serial ports on PCs.
> >
> > There is a crying need for a USB BMD pod for under $300, but I
don't know
> > of any. Has anyone else heard of one?
> >
> > Best regards, John Hartman
> > john@n...
> > NoICE Debugging Tools
> > http://www.noicedebugger.com
> >
> >
>
> -------------------- >
> ">http://docs.yahoo.com/info/terms/




Hi Christian.

For sure, the Metrowerks v1.2 IDE was released to support the DP256,
including bus speed change via PLL.
However, the P&E multilink\Cable12(HS) target interface (called ICD12) has
been upgraded due to PLL synchronization problem.
The Metrowerks support team has the upgraded "icd12.tgt" file you need, I
will forward this email to them (in CC), so they can contact you.
Note that if you use a Motorola SDI cable, it is not possible to debug with
a bus speed higher than 8 MHz (16 MHz osc).
If you already have this upgrade, make sure that the "set CLKSW bit in
BDM..." checkbox is checked in the "Communication Device Specification" dialog.

Regards,
Gilles

At 06:27 PM 2/12/2003, you wrote:
>Hi Michael,
>
>...as I come across your posting I wonder if the "BDM looses
>sync..." problem is why I have the problem to debug my same EvalKit
>target using the Metrowerks v1.2 IDE on the DP256 controller as if I
>choose the:
>
>1) PLL divider/multiplier REFDV=8, SYNR=6 I can halt and break the
>code within the debugger, but choosing
>
>2)PLL ... REFDV=1, SYNR=2 for my needed 24MHz ECLK I can't look at
>any RAM/Flash symbols within the debugger anymore... and this errata
>says that multiplier shouldn't be equal or greater than 2! Is this
>the SYNR reg? Than I have a problem 'cause how you can synthesize
>24MHz ECLK for a mask 3 (1k79x)with what kind of PLL params???
>
>And this problem is directly coupled to the last "Reading
>permanently '0's..." problem I posted several times! I can't look at
>if my serial interface output over SCI subsystem on my terminal is
>writing the right samples I got or not in my char array out there!!!
>
>Hope that now you better understand my problem dedicated with reading
>the port inputs every 1us! Any idea, hint? >Hope you can help hereby or telling me some test workaround or
>something else to get on... ):
>
>Christian >--- In , Mike Burns <mjb@c...> wrote:
> > Hi Bruce,
> >
> > HCS12 parts are supposed to derive the BDM communications clock
>directly
> > from the crystal so changes in the bus speed via the PLL should
>have no
> > affect on BDM SYNC. This worked fine in earlier versions of the
>DP256 and I
> > believe it works fine in all of the other HCS12 parts.
> >
> > However, MCS912DP256 (and DT256, DJ256, DG256) mask 2 (0K79X) and 3
>(1K79X)
> > a new problem was introduced (2001) and errata was issued "BDM
>LOSES SYNC
> > WHEN USING PLL AT HIGH FREQUENCIES"
> > http://e-www.motorola.com/brdata/PDFDB/docs/MC9S12DP256BMSE3.pdf
> >
> > As a result of this errata, both Cosmic and P&E modified their
>tools. The
> > Cosmic ZAP BDM debugger includes an option for chips with this
>errata that
> > allows transparent debugging through a PLL bus speed change. The
>SYNC
> > option has actually been in use for over a year. The
>debugger/cable also
> > work with the more standard BDM SYNC which is the default out of
>reset.
> >
> >
> > Best Regards,
> > Michael Burns
> > Cosmic Software
> >
> >
> > -----Original Message-----
> > From: Bruce McMillan [mailto:bruce.mcmillan@P...]
> > Sent: Thursday, January 09, 2003 10:31 PM
> > To:
> > Subject: Re: [68HC12] M68KIT912DP256
> >
> >
> > John,
> > thanks for the survey.
> > We also need the debuggers to support the s12 PLL running faster
>than
> > 8MHz. (Motorola bugs 'n all.)
> > cheers. Bruce
> >
> > John Hartman (NoICE) wrote:
> >
> > >>Well, there are other BDM emulators for the HC12/HCS12 available
>in the
> > >>market. And guess what? They don't have any of the reported
>problems here.
> > >>Nohau is selling a BDM for $1990, plugging to either USB, LPT
>port or a
> > >>
> > >
> > > Doron is right. Here are some that have worked well for me
>(supported by
> > > NoICE), all costing less than ($full featured)/10.
> > >
> > > Elektronikladen ComPOD12, available from MCT
>Elektronikladen GbR
> > > (http://www.elektronikladen.de/noicebdm12.html)
> > > Technological Arts microBDM12SX, available from
>Technological Arts
> >
> > > (http://www.technologicalarts.com)
> > > Kevin Ross BDM12, available from Kevin Ross
> > > (http://www.nwlink.com/~kevinro/bdm.html)
> > > P&E CABLE12 and MULTILINK, available from P&E
>Microcomputer
> > Systems
> > > (http://pemicro.com)
> > > Axiom AX-BDM12, available from Axiom Manufacturing
>Company
> > > (http://www.axman.com)
> > >
> > > The first three are serial devices. Slower than parallel port,
>but happy
> > > with longer cables from the PC, and no driver voodoo or port
>compatibility
> >
> > > issues.
> > >
> > > The parallel ports ones generally work well, but Billy G. keeps
>making it
> > > harder to connect widgets to parallel ports, and has decreed the
>eventual
> > > end of both parallel and serial ports on PCs.
> > >
> > > There is a crying need for a USB BMD pod for under $300, but I
>don't know
> > > of any. Has anyone else heard of one?
> > >
> > > Best regards, John Hartman
> > > john@n...
> > > NoICE Debugging Tools
> > > http://www.noicedebugger.com
> > >
> > >
> >
> >
> >
> >
> > --------------------
> >
> >
> >
> > ">http://docs.yahoo.com/info/terms/ >-------------------- >
>">http://docs.yahoo.com/info/terms/





Hi Gilles,

...first of all thanx for answering and give me the feeling I'm not
alone out there with Metrowerks? dedicated problems...;)

OK, hmmhh, hope I have no SDI cable you mentioned. I have the "BDM-
Multilink HC12-HCS12 Parallel Port BDM Interface" as you can read on
the label of the adapter with approx. 28cm 6-pin Berg cable and DSUB-
25 female cable connection to host. This Rev.B device runs with 2V-5V
and comes from P&E Microcomputer Systems Inc. with numbers:
- P: 617-353-9206 (part number?)
- F: 617-353-9205

I think it's one of the newer BDMs, not SDIs! OK, and in Metrowerks
CodeWarrior I take ICD-12 as the based project files as I assume and
do for some time hopefully in the right way - but I can flash over
BDM so I think it works :)
Note, that I have always set CLKSW bit as for "Set CLKSW bit in BDM
control register (MC9S12 only)" in debugger's menu tree "ICD-
12/Connect..." by opening the "Communication Device Specification"
dialog box you told us.

Ok, and icd12.tgt is a project-related target file for the debug
interface initialization, right? This file that I found in
my ..\progs directory is from '20.09.01 09:10' with original non-
altered Metrowerks timestamp. Ok, I will be waiting for an answer of
them, will I? Thanx for your help as always :-))

Christian --- In , Gilles Blanquin <gblanquin@m...> wrote:
>
> Hi Christian.
>
> For sure, the Metrowerks v1.2 IDE was released to support the
DP256,
> including bus speed change via PLL.
> However, the P&E multilink\Cable12(HS) target interface (called
ICD12) has
> been upgraded due to PLL synchronization problem.
> The Metrowerks support team has the upgraded "icd12.tgt" file you
need, I
> will forward this email to them (in CC), so they can contact you.
> Note that if you use a Motorola SDI cable, it is not possible to
debug with
> a bus speed higher than 8 MHz (16 MHz osc).
> If you already have this upgrade, make sure that the "set CLKSW bit
in
> BDM..." checkbox is checked in the "Communication Device
Specification" dialog.
>
> Regards,
> Gilles
>
> At 06:27 PM 2/12/2003, you wrote:
> >Hi Michael,
> >
> >...as I come across your posting I wonder if the "BDM looses
> >sync..." problem is why I have the problem to debug my same EvalKit
> >target using the Metrowerks v1.2 IDE on the DP256 controller as if
I
> >choose the:
> >
> >1) PLL divider/multiplier REFDV=8, SYNR=6 I can halt and break the
> >code within the debugger, but choosing
> >
> >2)PLL ... REFDV=1, SYNR=2 for my needed 24MHz ECLK I can't look at
> >any RAM/Flash symbols within the debugger anymore... and this
errata
> >says that multiplier shouldn't be equal or greater than 2! Is this
> >the SYNR reg? Than I have a problem 'cause how you can synthesize
> >24MHz ECLK for a mask 3 (1k79x)with what kind of PLL params???
> >
> >And this problem is directly coupled to the last "Reading
> >permanently '0's..." problem I posted several times! I can't look
at
> >if my serial interface output over SCI subsystem on my terminal is
> >writing the right samples I got or not in my char array out
there!!!
> >
> >Hope that now you better understand my problem dedicated with
reading
> >the port inputs every 1us! Any idea, hint?
> >
> >
> >Hope you can help hereby or telling me some test workaround or
> >something else to get on... ):
> >
> >Christian
> >
> >
> >--- In , Mike Burns <mjb@c...> wrote:
> > > Hi Bruce,
> > >
> > > HCS12 parts are supposed to derive the BDM communications clock
> >directly
> > > from the crystal so changes in the bus speed via the PLL should
> >have no
> > > affect on BDM SYNC. This worked fine in earlier versions of the
> >DP256 and I
> > > believe it works fine in all of the other HCS12 parts.
> > >
> > > However, MCS912DP256 (and DT256, DJ256, DG256) mask 2 (0K79X)
and 3
> >(1K79X)
> > > a new problem was introduced (2001) and errata was issued "BDM
> >LOSES SYNC
> > > WHEN USING PLL AT HIGH FREQUENCIES"
> > > http://e-www.motorola.com/brdata/PDFDB/docs/MC9S12DP256BMSE3.pdf
> > >
> > > As a result of this errata, both Cosmic and P&E modified their
> >tools. The
> > > Cosmic ZAP BDM debugger includes an option for chips with this
> >errata that
> > > allows transparent debugging through a PLL bus speed change.
The
> >SYNC
> > > option has actually been in use for over a year. The
> >debugger/cable also
> > > work with the more standard BDM SYNC which is the default out of
> >reset.
> > >
> > >
> > > Best Regards,
> > > Michael Burns
> > > Cosmic Software
> > >
> > >
> > > -----Original Message-----
> > > From: Bruce McMillan [mailto:bruce.mcmillan@P...]
> > > Sent: Thursday, January 09, 2003 10:31 PM
> > > To:
> > > Subject: Re: [68HC12] M68KIT912DP256
> > >
> > >
> > > John,
> > > thanks for the survey.
> > > We also need the debuggers to support the s12 PLL running faster
> >than
> > > 8MHz. (Motorola bugs 'n all.)
> > > cheers. Bruce
> > >
> > > John Hartman (NoICE) wrote:
> > >
> > > >>Well, there are other BDM emulators for the HC12/HCS12
available
> >in the
> > > >>market. And guess what? They don't have any of the reported
> >problems here.
> > > >>Nohau is selling a BDM for $1990, plugging to either USB, LPT
> >port or a
> > > >>
> > > >
> > > > Doron is right. Here are some that have worked well for me
> >(supported by
> > > > NoICE), all costing less than ($full featured)/10.
> > > >
> > > > Elektronikladen ComPOD12, available from MCT
> >Elektronikladen GbR
> > > > (http://www.elektronikladen.de/noicebdm12.html)
> > > > Technological Arts microBDM12SX, available from
> >Technological Arts
> > >
> > > > (http://www.technologicalarts.com)
> > > > Kevin Ross BDM12, available from Kevin Ross
> > > > (http://www.nwlink.com/~kevinro/bdm.html)
> > > > P&E CABLE12 and MULTILINK, available from P&E
> >Microcomputer
> > > Systems
> > > > (http://pemicro.com)
> > > > Axiom AX-BDM12, available from Axiom Manufacturing
> >Company
> > > > (http://www.axman.com)
> > > >
> > > > The first three are serial devices. Slower than parallel
port,
> >but happy
> > > > with longer cables from the PC, and no driver voodoo or port
> >compatibility
> > >
> > > > issues.
> > > >
> > > > The parallel ports ones generally work well, but Billy G.
keeps
> >making it
> > > > harder to connect widgets to parallel ports, and has decreed
the
> >eventual
> > > > end of both parallel and serial ports on PCs.
> > > >
> > > > There is a crying need for a USB BMD pod for under $300, but I
> >don't know
> > > > of any. Has anyone else heard of one?
> > > >
> > > > Best regards, John Hartman
> > > > john@n...
> > > > NoICE Debugging Tools
> > > > http://www.noicedebugger.com
> > > >
> > > >
> > >
> > >
> > >
> > >
> > > --------------------
> > >
> > >
> > >
> > > ">http://docs.yahoo.com/info/terms/
> >
> >
> >--------------------
> >
> >
> >
> >">http://docs.yahoo.com/info/terms/


Hi Christian , Gilles and Metrowerks support

I'm having exactly the same problem with the DP256 / Metrowerks V1.2 and P&E
Multilink Cable 12 (HS). At 8 Mhz everything goes wright, but when I use the PLL to
bring the clock up to 24 Mhz I can't debug anymore...
Please forward me any reply / solution (if there is one.)

Thank you very much for your help.
Regards,

Guillermo F. Molina

Buenos Aires
ARGENTINA.

On 13 Feb 2003 at 11:06, Gilles Blanquin wrote:

>
> Hi Christian.
>
> For sure, the Metrowerks v1.2 IDE was released to support the DP256,
> including bus speed change via PLL.
> However, the P&E multilink\Cable12(HS) target interface (called ICD12) has
> been upgraded due to PLL synchronization problem.
> The Metrowerks support team has the upgraded "icd12.tgt" file you need, I
> will forward this email to them (in CC), so they can contact you.
> Note that if you use a Motorola SDI cable, it is not possible to debug with
> a bus speed higher than 8 MHz (16 MHz osc).
> If you already have this upgrade, make sure that the "set CLKSW bit in
> BDM..." checkbox is checked in the "Communication Device Specification" dialog.
>
> Regards,
> Gilles
>
> At 06:27 PM 2/12/2003, you wrote:
> >Hi Michael,
> >
> >...as I come across your posting I wonder if the "BDM looses
> >sync..." problem is why I have the problem to debug my same EvalKit
> >target using the Metrowerks v1.2 IDE on the DP256 controller as if I
> >choose the:
> >
> >1) PLL divider/multiplier REFDV=8, SYNR=6 I can halt and break the
> >code within the debugger, but choosing
> >
> >2)PLL ... REFDV=1, SYNR=2 for my needed 24MHz ECLK I can't look at
> >any RAM/Flash symbols within the debugger anymore... and this errata
> >says that multiplier shouldn't be equal or greater than 2! Is this
> >the SYNR reg? Than I have a problem 'cause how you can synthesize
> >24MHz ECLK for a mask 3 (1k79x)with what kind of PLL params???
> >
> >And this problem is directly coupled to the last "Reading
> >permanently '0's..." problem I posted several times! I can't look at
> >if my serial interface output over SCI subsystem on my terminal is
> >writing the right samples I got or not in my char array out there!!!
> >
> >Hope that now you better understand my problem dedicated with reading
> >the port inputs every 1us! Any idea, hint?
> >
> >
> >Hope you can help hereby or telling me some test workaround or
> >something else to get on... ):
> >
> >Christian
> >
> >
> >--- In , Mike Burns <mjb@c...> wrote:
> > > Hi Bruce,
> > >
> > > HCS12 parts are supposed to derive the BDM communications clock
> >directly
> > > from the crystal so changes in the bus speed via the PLL should
> >have no
> > > affect on BDM SYNC. This worked fine in earlier versions of the
> >DP256 and I
> > > believe it works fine in all of the other HCS12 parts.
> > >
> > > However, MCS912DP256 (and DT256, DJ256, DG256) mask 2 (0K79X) and 3
> >(1K79X)
> > > a new problem was introduced (2001) and errata was issued "BDM
> >LOSES SYNC
> > > WHEN USING PLL AT HIGH FREQUENCIES"
> > > http://e-www.motorola.com/brdata/PDFDB/docs/MC9S12DP256BMSE3.pdf
> > >
> > > As a result of this errata, both Cosmic and P&E modified their
> >tools. The
> > > Cosmic ZAP BDM debugger includes an option for chips with this
> >errata that
> > > allows transparent debugging through a PLL bus speed change. The
> >SYNC
> > > option has actually been in use for over a year. The
> >debugger/cable also
> > > work with the more standard BDM SYNC which is the default out of
> >reset.
> > >
> > >
> > > Best Regards,
> > > Michael Burns
> > > Cosmic Software
> > >
> > >
> > > -----Original Message-----
> > > From: Bruce McMillan [mailto:bruce.mcmillan@P...]
> > > Sent: Thursday, January 09, 2003 10:31 PM
> > > To:
> > > Subject: Re: [68HC12] M68KIT912DP256
> > >
> > >
> > > John,
> > > thanks for the survey.
> > > We also need the debuggers to support the s12 PLL running faster
> >than
> > > 8MHz. (Motorola bugs 'n all.)
> > > cheers. Bruce
> > >
> > > John Hartman (NoICE) wrote:
> > >
> > > >>Well, there are other BDM emulators for the HC12/HCS12 available
> >in the
> > > >>market. And guess what? They don't have any of the reported
> >problems here.
> > > >>Nohau is selling a BDM for $1990, plugging to either USB, LPT
> >port or a
> > > >>
> > > >
> > > > Doron is right. Here are some that have worked well for me
> >(supported by
> > > > NoICE), all costing less than ($full featured)/10.
> > > >
> > > > Elektronikladen ComPOD12, available from MCT
> >Elektronikladen GbR
> > > > (http://www.elektronikladen.de/noicebdm12.html)
> > > > Technological Arts microBDM12SX, available from
> >Technological Arts
> > >
> > > > (http://www.technologicalarts.com)
> > > > Kevin Ross BDM12, available from Kevin Ross
> > > > (http://www.nwlink.com/~kevinro/bdm.html)
> > > > P&E CABLE12 and MULTILINK, available from P&E
> >Microcomputer
> > > Systems
> > > > (http://pemicro.com)
> > > > Axiom AX-BDM12, available from Axiom Manufacturing
> >Company
> > > > (http://www.axman.com)
> > > >
> > > > The first three are serial devices. Slower than parallel port,
> >but happy
> > > > with longer cables from the PC, and no driver voodoo or port
> >compatibility
> > >
> > > > issues.
> > > >
> > > > The parallel ports ones generally work well, but Billy G. keeps
> >making it
> > > > harder to connect widgets to parallel ports, and has decreed the
> >eventual
> > > > end of both parallel and serial ports on PCs.
> > > >
> > > > There is a crying need for a USB BMD pod for under $300, but I
> >don't know
> > > > of any. Has anyone else heard of one?
> > > >
> > > > Best regards, John Hartman
> > > > john@n...
> > > > NoICE Debugging Tools
> > > > http://www.noicedebugger.com
> > > >
> > > >
> > >
> > >
> > >
> > >
> > > --------------------
> > >
> > >
> > >
> > > ">http://docs.yahoo.com/info/terms/
> >
> >
> >--------------------
> >
> >
> >
> >">http://docs.yahoo.com/info/terms/ >
> -------------------- >
> ">http://docs.yahoo.com/info/terms/