Reply by christian_theiss_2003 February 14, 20032003-02-14
Hi Guillermo and people who had same problems!

...provided that we did all the setups Gilles and the archives told
us we have to contact ' to get this
newer? "icd-12.tgt" file which probably should fix our very hard-to-
find problem with ECKLs going beyond the 8MHz border got from a fixed
16MHz oscillator clock and now extending this by selecting a higher
PLLCLK, for e.g. 48MHz for generation of a <bus clock>K$MHz!

So taking into consideration that Gilles carbon-copied his posting
before to the support team we have to wait for an official answer
from them! This problem probably is dedicated more to support teams
than R&Ds as we now surely could assume... :)
Ok, and I am not sure - probably you have to
contact ' for the south americas - but look at
your contract documents which is the right email address to contact
the right location!-) Best regards and happy developing

Christian

--- In , "Guillermo F. Molina" <gmolina@m...>
wrote:
> 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
> gmolina@m...
> 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/
> >
> >




Reply by Guillermo F. Molina February 13, 20032003-02-13
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/



Reply by christian_theiss_2003 February 13, 20032003-02-13
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/


Reply by Gilles Blanquin February 13, 20032003-02-13

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/





Reply by christian_theiss_2003 February 12, 20032003-02-12
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/



Reply by Stephen Trier January 13, 20032003-01-13
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


Reply by Karl Lunt January 13, 20032003-01-13


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



Reply by James M. Knox January 13, 20032003-01-13
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
-----------



Reply by Mark Cukier January 12, 20032003-01-12
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>
>


Reply by James M. Knox January 12, 20032003-01-12
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
-----------