new BDM multilink

Started by Mr angel castillo May 12, 2004
Hello

i`m new in this list.

i live in monterrey, mexico

i have a new BDM multilink cable of PEMICRO Company

i have problems for conect a MC68hc912B32 with the
software true-time simulator and real time debuger of
code warrior.

but when i use a target board with MS912dg128, the
software and hardware work very well.

i have a pc pentium IV 1.7 Ghz, with xp home.

tanks in advance

ANgel castillo
_________________________________________________________

This thread is also related in my case to a question in another thread "How much clock variance can BDM's tolerate?"

There is a P&E patch you can down load for Windows XP if you are using the Parallel port version of the cable. After installing the patch I have found neither the Parallel or a USB BDM to be stable. Although the BDM had been stable with my previous PC running NT4.

The Crystal is: 3686400 (Colpits oscillator)
And the Bus is: 15,974,400Hz
PLL derived from Crystal / 3 * 13.

I think the problem is the Motorola 9S12 BDM, is far less robust than others such as HC16 BDM. The tool makes are doing the best they can with it. Andrew Lohmann AIIE
Design Engineer

PLEASE NOTE NEW EMAIL ADDRESS IS: Bellingham + Stanley Ltd.
Longfield Road, Tunbridge Wells, Kent, TN2 3EY, England.
Tel: +44 (0) 1892 500400
Fax: +44 (0) 1892 543115
Website: www.bs-ltd.com

----- Original Message -----
From: Mr angel castillo
To:
Sent: Thursday, May 13, 2004 1:07 AM
Subject: [68HC12] new BDM multilink Hello

i`m new in this list.

i live in monterrey, mexico

i have a new BDM multilink cable of PEMICRO Company

i have problems for conect a MC68hc912B32 with the
software true-time simulator and real time debuger of
code warrior.

but when i use a target board with MS912dg128, the
software and hardware work very well.

i have a pc pentium IV 1.7 Ghz, with xp home.

tanks in advance

ANgel castillo



Some BDMs do better than others in this regard of BDM communication stability.

With the Nohau BDM algorithm, you input the crystal frequency and the SYNR
and REFDV PLL values to the debugger, and the BDM programs the PLL and
engages it. In this method the BDM doesn't suffer from any communication
instability, and you can use any desirable (or even exotic if you wish)
crystal frequency and PLL values.

Some BDMs attempt to detect the target frequency experimentally (by trying
different BDM frequencies, and seeing if one happens to work). That's when
things start to get messy, because these algorithms are not very reliable,
can change register contents in the process of the detection the frequency,
and sometimes zoom in on a BDM frequency that is different from the actual
HC12 frequency, and is therefore communicating marginally.

So, it is true that the HC12/HCS12 BDM is less robust than the HC16 in
regard to communication frequency. But still there is a way for the
HC12/HCS12 BDMs to communicate appropriately and in a stable manner when
the correct method is used.

Doron
Nohau Corporation
HC12 In-Circuit Emulators
www.nohau.com/emul12pc.html

At 09:23 13/05/2004 +0100, you wrote:
>This thread is also related in my case to a question in another thread
>"How much clock variance can BDM's tolerate?"
>
>There is a P&E patch you can down load for Windows XP if you are using the
>Parallel port version of the cable. After installing the patch I have
>found neither the Parallel or a USB BDM to be stable. Although the BDM had
>been stable with my previous PC running NT4.
>
>The Crystal is: 3686400 (Colpits oscillator)
>And the Bus is: 15,974,400Hz
>PLL derived from Crystal / 3 * 13.
>
>I think the problem is the Motorola 9S12 BDM, is far less robust than
>others such as HC16 BDM. The tool makes are doing the best they can with it. >Andrew Lohmann AIIE
>Design Engineer
>
>PLEASE NOTE NEW EMAIL ADDRESS IS: >Bellingham + Stanley Ltd.
>Longfield Road, Tunbridge Wells, Kent, TN2 3EY, England.
>Tel: +44 (0) 1892 500400
>Fax: +44 (0) 1892 543115
>Website: www.bs-ltd.com
>
> ----- Original Message -----
> From: Mr angel castillo
> To:
> Sent: Thursday, May 13, 2004 1:07 AM
> Subject: [68HC12] new BDM multilink > Hello
>
> i`m new in this list.
>
> i live in monterrey, mexico
>
> i have a new BDM multilink cable of PEMICRO Company
>
> i have problems for conect a MC68hc912B32 with the
> software true-time simulator and real time debuger of
> code warrior.
>
> but when i use a target board with MS912dg128, the
> software and hardware work very well.
>
> i have a pc pentium IV 1.7 Ghz, with xp home.
>
> tanks in advance
>
> ANgel castillo




Thanks Mark, I shall contact you off-list, but before doing that I clear up some points.

> USB port-- did you only notice this after installing the patch, etc?

I started out with the parallel version, which was unstable without and then with the P&E XP Patch. I swapped parrallel with my collegues USB because his reported - could not erase the flash or something, we where both satisfied after the swap. We now both have the XP Pro patch and both find the target losses syncronisation periodically.

I have also since started using a newer target PCB where the PLL and colpits oscillator is even more carefully designed than the first. This is more stable than the first, but the first target was compleltely stable for a month on so prior to my switch to XP Pro and new PC. I could find the old pc, though it's OS has change and I have in anycase transfered the Cosmic Zap licence, though I do have other debuggers I could try.

Do I also understand from your comment that, using other than 1 - 2- 4 - 8 - 16 or 24 MHz oscillator as I do should not be an issue with Multilink or is that only the case with cyclone?

>This thread is also related in my case to a question in another thread "How much clock variance can BDM's tolerate?"
>
>There is a P&E patch you can down load for Windows XP if you are using the Parallel port version of the cable. After installing the patch I have found neither the Parallel or a USB BDM to be stable. Although the BDM had been stable with my previous PC running NT4.
>
>The Crystal is: 3686400 (Colpits oscillator)
>And the Bus is: 15,974,400Hz
>PLL derived from Crystal / 3 * 13.
>
>I think the problem is the Motorola 9S12 BDM, is far less robust than others such as HC16 BDM. The tool makes are doing the best they can with it.
>


Andrew Lohmann AIIE
Design Engineer

PLEASE NOTE NEW EMAIL ADDRESS IS: Bellingham + Stanley Ltd.
Longfield Road, Tunbridge Wells, Kent, TN2 3EY, England.
Tel: +44 (0) 1892 500400
Fax: +44 (0) 1892 543115
Website: www.bs-ltd.com




Andrew:

The patch we provide is a registry entry to turn off the "Auto Scan"
feature of WinXP. This winXP "feature" will occasionally toggle the
parallel port to detect any plug and play devices. Obviously, this can
wreak havoc on any BDM communication occurring across this same port!
I'd definitely be interested to hear the details of the instability
you're observing, most notably across the USB port-- did you only notice
this after installing the patch, etc?

In regards to "how much clock variance can BDMs tolerate", the answer
for the BDM Multilink/Cyclone products is, practically speaking, "any".
As Doron pointed out, we test across and beyond the whole range of BDM
frequencies to establish a communication frequency-- however, we test
across ALL frequencies (even if we get a sucessfull communication early
on) before deciding the range on which to zero in on. So, no matter what
frequency your target is running at, we can talk to it. (we chose this
method to allow the user's code, rather than the user himself, to change
the PLL frequency-- just as would happen on an actual running target).

Please let me know the details of your issue offlist (or onlist if you
believe the group will benefit!)-- though the HC(s)12 BDM is not ideal,
you should be at least be stable!!!

Regards,
Mark
P&E Andrew Lohmann's New Email Server wrote:

>This thread is also related in my case to a question in another thread "How much clock variance can BDM's tolerate?"
>
>There is a P&E patch you can down load for Windows XP if you are using the Parallel port version of the cable. After installing the patch I have found neither the Parallel or a USB BDM to be stable. Although the BDM had been stable with my previous PC running NT4.
>
>The Crystal is: 3686400 (Colpits oscillator)
>And the Bus is: 15,974,400Hz
>PLL derived from Crystal / 3 * 13.
>
>I think the problem is the Motorola 9S12 BDM, is far less robust than others such as HC16 BDM. The tool makes are doing the best they can with it. >Andrew Lohmann AIIE
>Design Engineer
>
>PLEASE NOTE NEW EMAIL ADDRESS IS: >Bellingham + Stanley Ltd.
>Longfield Road, Tunbridge Wells, Kent, TN2 3EY, England.
>Tel: +44 (0) 1892 500400
>Fax: +44 (0) 1892 543115
>Website: www.bs-ltd.com
>
> ----- Original Message -----
> From: Mr angel castillo
> To:
> Sent: Thursday, May 13, 2004 1:07 AM
> Subject: [68HC12] new BDM multilink > Hello
>
> i`m new in this list.
>
> i live in monterrey, mexico
>
> i have a new BDM multilink cable of PEMICRO Company
>
> i have problems for conect a MC68hc912B32 with the
> software true-time simulator and real time debuger of
> code warrior.
>
> but when i use a target board with MS912dg128, the
> software and hardware work very well.
>
> i have a pc pentium IV 1.7 Ghz, with xp home.
>
> tanks in advance
>
> ANgel castillo >
>
>--------------------To learn more about Motorola Microcontrollers, please visit
>http://www.motorola.com/mcu
>o learn more about Motorola Microcontrollers, please visit
>http://www.motorola.com/mcu
>
>Yahoo! Groups Links >

--

____________________________
Mark L. Cukier, Design Engineer
P&E Microcomputer Systems
710 Commonwealth Avenue
Boston, MA 02215
_________________________________
e-mail:
phone : (617) 353-9206 x19
fax : (617) 353-9205
_________________________________

visit us on the web at: http: //www.pemicro.com



Andrew:

That is correct, we can handle any oscillator value with the Multilink
as well as the Cyclone!

Regards,
Mark
P&E

Andrew Lohmann's New Email Server wrote:

>Thanks Mark, >I shall contact you off-list, but before doing that I clear up some points. >
>>USB port-- did you only notice this after installing the patch, etc?
>>
>>
>
>I started out with the parallel version, which was unstable without and then with the P&E XP Patch. I swapped parrallel with my collegues USB because his reported - could not erase the flash or something, we where both satisfied after the swap. We now both have the XP Pro patch and both find the target losses syncronisation periodically.
>
>I have also since started using a newer target PCB where the PLL and colpits oscillator is even more carefully designed than the first. This is more stable than the first, but the first target was compleltely stable for a month on so prior to my switch to XP Pro and new PC. I could find the old pc, though it's OS has change and I have in anycase transfered the Cosmic Zap licence, though I do have other debuggers I could try.
>
>Do I also understand from your comment that, using other than 1 - 2- 4 - 8 - 16 or 24 MHz oscillator as I do should not be an issue with Multilink or is that only the case with cyclone? >
>>This thread is also related in my case to a question in another thread "How much clock variance can BDM's tolerate?"
>>
>>There is a P&E patch you can down load for Windows XP if you are using the Parallel port version of the cable. After installing the patch I have found neither the Parallel or a USB BDM to be stable. Although the BDM had been stable with my previous PC running NT4.
>>
>>The Crystal is: 3686400 (Colpits oscillator)
>>And the Bus is: 15,974,400Hz
>>PLL derived from Crystal / 3 * 13.
>>
>>I think the problem is the Motorola 9S12 BDM, is far less robust than others such as HC16 BDM. The tool makes are doing the best they can with it.
>>
>>
> >Andrew Lohmann AIIE
>Design Engineer
>
>PLEASE NOTE NEW EMAIL ADDRESS IS: >Bellingham + Stanley Ltd.
>Longfield Road, Tunbridge Wells, Kent, TN2 3EY, England.
>Tel: +44 (0) 1892 500400
>Fax: +44 (0) 1892 543115
>Website: www.bs-ltd.com >--------------------To learn more about Motorola Microcontrollers, please visit
>http://www.motorola.com/mcu
>o learn more about Motorola Microcontrollers, please visit
>http://www.motorola.com/mcu
>
>Yahoo! Groups Links >

--

____________________________
Mark L. Cukier, Design Engineer
P&E Microcomputer Systems
710 Commonwealth Avenue
Boston, MA 02215
_________________________________
e-mail:
phone : (617) 353-9206 x19
fax : (617) 353-9205
_________________________________

visit us on the web at: http: //www.pemicro.com


--- "Mark L. Cukier" <> escribi >
Andrew:
>
> The patch we provide is a registry entry to turn off
> the "Auto Scan"
> feature of WinXP. This winXP "feature" will
> occasionally toggle the
>

How can i get this patch.

thanks

_________________________________________________________
At 01:23 AM 5/13/2004, Andrew Lohmann wrote:

>...
>I think the problem is the Motorola 9S12 BDM, is far less robust than
>others such as HC16 BDM. The tool makes are doing the best they can with it.

Having had experience with both the HC16 and HC12 and their BDM support
issues, I don't entirely agree.

The HC16 BDM took 2 pins. The cost improved HC(S)-12 BDM uses only 1 pin.

The sacrifice involved was that the host end of the BDM channel MUST know
the current target BDM clock fairly accurately in order to get successful
communication.

Motorola keeps reducing the annoyance of this sacrifice, but its still there.

A related problem that confuses both HC-16 and HC-12 users when bringing up
a new board is getting the on-chip clock stable. Especially in designs
that use a crystal and the on-chip PLL, this is a challenge anyway.

When the MCU clock is even slightly unstable, the MCU will react by
executing instructions incorrectly or not at all. This usually produces
completely incomprehensible debugging information.

With the HC-16 it is a little easier to sort out all these confusions, but
with the HC(S)-12 they all have one symptom: "The BDM doesn't work."

The MORALS:

Recognize that crystal and PLL problems are layout and component sensitive,
and use careful design and board layout, and good lab technique when
bringing the board up.

If at all possible, arrange to separate the commissioning of the BDM
connection and debugger from the debugging of the crystal and PLL hardware
details.

(Perhaps use an external clock source to for initial testing of the BDM and
the MCU functioning before attempting to get the crystal working. Make
sure the crystal is stable and the BDM working before attempting to use the
PLL. Check that ECLK output is very stable with both the crystal and the PLL.)

Rejoice that you get higher speed, more memory and peripherals on-chip on a
HC(S)-12 part at the same or lower price as for an HC-16.

When debugging clock speed changes combined with COP resets, remember that
a Nohau full emulator presents the instruction executions, data reads and
writes, and resets and puts a timestamp one each one.

Steve Russell
Nohau Emulators *************************************************************************
Steve Russell mailto:
Senior Software Design Engineer http://www.nohau.com
Nohau Corporation phone: (408)866-1820 ext. 1873
51 East Campbell Avenue fax: (408)378-7869
Campbell, CA 95008
*************************************************************************



I just read Steve's comment that some designers have had problems
with crystal-based PLL designs.

I am trying to finalize a 9s12 design. I now have a design that uses
an oscillator, but I was thinking about switching to a crystal. But
after reading Steve's comments about clock stability I am wondering
if this is a good idea. My board is pretty dense, and I don't have
enough space to literally reproduce Motorola's "recommended" layout,
although I think I have a good short path layout anyway.

Steve, you've obviously been around the 9s12 for quite a while. Have
you seen a lot of PLL stability problems among your clients? Maybe I
should stay with the oscillator as a way of buying a little extra
stability, sort of insurance against a "design adventure." The fact
that Motorola publishes a specific layout suggests those PLL's are
pretty touchy...

Bill T.
http://www.kupercontrols.com

Thanks group for your comments on the ECLK timing. I think I'm going
to add some delay buffers in front of my fpga address & data input
latches.



At 05:17 PM 5/13/2004, Bill T. wrote:

>My board is pretty dense, and I don't have enough space to literally
>reproduce Motorola's "recommended" layout, although I think I have a good
>short path layout anyway.

I guess that if the crystal and its capacitor leads are about as short as
the Motorola recommendation there shouldn't be much trouble.

The bypass capacitors and power supply routing are quite important because
they deal with relatively high current high frequency signals that can
easily spread to the rest of the system.

The PLL leads are lower frequency, and the PLL filter is much more
forgiving of component choice, so longer leads shouldn't hurt if they don't
pick up noise.

My guess is that the ground plane details are important to squeeze the last
bit of accuracy out of the ADC.

>Steve, you've obviously been around the 9s12 for quite a while. Have
>you seen a lot of PLL stability problems among your clients? Maybe I
>should stay with the oscillator as a way of buying a little extra
>stability, sort of insurance against a "design adventure." The fact
>that Motorola publishes a specific layout suggests those PLL's are
>pretty touchy...

The short answer is: Yes, Canned oscillator is easier, but...

(Actually, I haven't personally designed a board for the HC(S)-12. Doron
Fael does that very well, so I don't.)

The problems with crystals and PLLs that I have seen are mostly support for
"Why doesn't your emulator work?" questions.

The source of the problems is usually due to overlooking the details in the
Motorola/Freescale documentation (easy to do, there's so much of it!) or
inexperience in analog and high frequency board design and layout. Crystals
--------

If you've gotten a crystal oscillator in the MHz range to work once, you
probably won't have too much trouble, IF you have read and understood
Motorola's and the crystal manufacturer's documentation.

There are 2 steps to getting the crystal running.

First, you need to get it to oscillate and produce a stable ECLK output.

Once the ECLK is stable, the problems left will mostly be starting after
reset or power on.

You probably should at least test startup and operation at high and low
temperatures to make sure you have some margin for production
variations. If end product is lab equipment, a refrigerator and a heat gun
may be adequate test equipment.

Yes, its more work that dropping in a canned oscillator, but volume
production is cheaper, it draws less current and the board space may be less.

If you need to operate over the full HC(S)-12 temperature range, then most
canned oscillators aren't specified for that, and you need a test chamber
and more time. PLL
---

Note that using the PLL is a separate choice from using a crystal.

The PLL problems that I have seen are the locking issue that I discussed
previously and "What's the XFC pin?".

The PLL filter has considerable latitude. You can see this by
experimenting with the Motorola PLL calculator. Experimentally, it works
with values well outside the recommended range. BUT you MUST have one!

If you understand that, and you plan your project so that activating the
PLL is done separately from any other features, you probably won't have
much trouble with the PLL.

If you need a very stable clock for some reason, then you may need to worry
more about the PLL filter.

Hope this helps

Steve Russell
Nohau Emulators *************************************************************************
Steve Russell mailto:
Senior Software Design Engineer http://www.nohau.com
Nohau Corporation phone: (408)866-1820 ext. 1873
51 East Campbell Avenue fax: (408)378-7869
Campbell, CA 95008
*************************************************************************