|
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 _________________________________________________________ |
|
|
new BDM multilink
Started by ●May 12, 2004
Reply by ●May 13, 20042004-05-13
|
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 |
|
|
Reply by ●May 13, 20042004-05-13
|
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 |
Reply by ●May 13, 20042004-05-13
|
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 |
|
|
Reply by ●May 13, 20042004-05-13
|
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 |
|
|
Reply by ●May 13, 20042004-05-13
|
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 |
Reply by ●May 13, 20042004-05-13
|
--- "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 _________________________________________________________ |
Reply by ●May 13, 20042004-05-13
|
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 ************************************************************************* |
|
|
Reply by ●May 13, 20042004-05-13
|
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. |
|
|
Reply by ●May 13, 20042004-05-13
|
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 ************************************************************************* |
