Hi all, why don't you take a look to inDART-HCS12? It is a full-featured BDM real-time programmer/debugger for all the Motorola HCS12 family. It is able to maintain the communication with the target at any frequency in these two ways: 1. Automatic Frequency and BDM4 Version Detection. If the device is new enough to support the BDM4 version, inDART-HCS12 uses both SYNC and ACK commands to synchronize the communication. 2. ECLK Frequency Synchronization. All the BDM commands are ever synchronized, also during CPU frequency changes. Here is the link to the SofTec Microsystems web page: http://www.softecmicro.com/products.html?typeail&title=inDART- HCS12%2FD Regards, Nicola --- In , "Andrew Lohmann's New Email Server" <andrew.lohmann@b...> wrote: > Dear Mark, > Thanks for replying. I have answered most of the points already. A while back you allowed me to trial a beta of P&E's ICD12 with high level support. I have already comment on that, it was a useful comparison with Cosmic Zap. I have also tried NoICE and generally find Zap the nicest to work with, and more tolerant to clock fluctuations - I guess it does not display any warning unless a fluctuation prevents it carrying out a command? > > There is a strangeness with both the NoICE and Zap, but not the ICD12, and unsecure 12 that the former at times will not connect, until they are closed and unsecure12 is run. This is as if there is an extra configuration of the BDM cable that ICD12, and unsecure 12 does that NoICE and Zap does not do. It is possible that my target is unduly noisy because I've also found that one make of SRAM does not work in one case whereas another make does in the other case. The oscillator and pll look good and clean - I know probing crystals with an oscilloscope can be misleading. > > Offlist I found the P&E BDM cable for HC16 wonderful some years ago - It seemed to work with the pll set any where even well outside the spec. It is as good as an emulator - whatever Noral say to put down BDM. That was 5 years ago and I think ICD12 which looks the same now looks old and cluttered - hope that comment is useful to you? > > I have an issue with XP Pro which is resolved by running in it in safemode, and whilst in safemode running Zap on consequently Mulitlink12. After running in safemode etc. then restarting normally the problem is resolved. The problem is that the mouse bounces about all over the screen, this is the case with mouse drive changed, using a usb mouse instead, and uninstalling most everything and progressively reinstalling it. The problem has only arrisen a month after software was reinstall and had until now been running reliably. > > > Thanks once again > Andrew Lohmann AIIE > Design Engineer > > PLEASE NOTE NEW EMAIL ADDRESS IS: > andrew.lohmann@b... > > 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 > >

Dear Mark, Thanks for replying. I have answered most of the points already. A while back you allowed me to trial a beta of P&E's ICD12 with high level support. I have already comment on that, it was a useful comparison with Cosmic Zap. I have also tried NoICE and generally find Zap the nicest to work with, and more tolerant to clock fluctuations - I guess it does not display any warning unless a fluctuation prevents it carrying out a command? There is a strangeness with both the NoICE and Zap, but not the ICD12, and unsecure 12 that the former at times will not connect, until they are closed and unsecure12 is run. This is as if there is an extra configuration of the BDM cable that ICD12, and unsecure 12 does that NoICE and Zap does not do. It is possible that my target is unduly noisy because I've also found that one make of SRAM does not work in one case whereas another make does in the other case. The oscillator and pll look good and clean - I know probing crystals with an oscilloscope can be misleading. Offlist I found the P&E BDM cable for HC16 wonderful some years ago - It seemed to work with the pll set any where even well outside the spec. It is as good as an emulator - whatever Noral say to put down BDM. That was 5 years ago and I think ICD12 which looks the same now looks old and cluttered - hope that comment is useful to you? I have an issue with XP Pro which is resolved by running in it in safemode, and whilst in safemode running Zap on consequently Mulitlink12. After running in safemode etc. then restarting normally the problem is resolved. The problem is that the mouse bounces about all over the screen, this is the case with mouse drive changed, using a usb mouse instead, and uninstalling most everything and progressively reinstalling it. The problem has only arrisen a month after software was reinstall and had until now been running reliably. Thanks once again 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

Steve Russell <> wrote: [...] > 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. In my experience, especially _with_ te PLL it's no problem. The only problem is IMHO to understand the component selection and configuration, which could be simplified with a better documentation. > When the MCU clock is even slightly unstable, the MCU will react by > executing instructions incorrectly or not at all. This usually produces The only situation when I oberved such behaviour was a D60A _without_ PLL during EMC test with EFT and (indirect) ESD. Seemingly the high impedance, low level EXTAL pin was influenced. And since there is only a /2 division ratio between EXTAL and E clock, it's not too surprising. But I guess that under these circumstances, the clock was not "slightly unstable" - likely the pulse duration was reduced beyond the minimum limit. With the PLL, transients don't affect the XFC voltage noticeable, and therefore even with several wrong EXTAL clock cycles, the E clock doesn't change very much. Especially true with a low PLL bandwidth (large capacitors). > The MORALS: > > Recognize that crystal and PLL problems are layout and component sensitive, the layout of the PLL filtering network is not too critical, is it? > and use careful design and board layout, and good lab technique when > bringing the board up. Ack. And people should try to learn how a crystal oscillator works and how to verify a correct design or ask someone at least when starting volume production. And the board designer should know which currents take which path... > 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 Correct, that's very useful for a painless start. Oliver -- Oliver Betz, Muenchen

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

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

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

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

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

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