Hello to All: I thought I'd chime in here with a few words in P&E's defense: It is true that PCI-based parallel ports are not registered in the bios and as such do not, by default, appear in the list of parallel ports you can access. However P&E has written a utility, ADDLPT, which allows you to specify where additional PCI parallel ports reside. After using this utility, P&E applications and other third party applications should be able to see your PCI parallel ports. P&E applications allow up to five different parallel ports to be selected. This utility is delivered with many P&E applications, although if you need a copy, please email me off-list and I will send you a copy. We will also put post this utility on our website. It should also be noted that many of our customers, and some of our developers, use winXP and our BDM tools with no issues whatsoever-- if you're having problems that you can't seem to iron out, please contact me offlist and I'll try to work through the issue with you. Most important, however, please be aware that we are indeed working on alternate interface BDM pods-- both USB and hopefully Ethernet as well. These should be available towards the end of Q1 2003-- and obviously this will eliminate these pesky parallel port issues! Cheers, Mark P&E wrote: > It is ridiculous that the P&E Multilink cable still requires a standard > parallel port. Throw in XP and we have not been able to get our cable to > work yet It will work under Win 98 but fails under XP even with the > port > configured to use interrupts. The other issue I have with a standard > parallel port is the only one you can have is the one built on your > mother > board. Under XP if you install a PCI parallel port you will be unable to > set it to the standard I/O address for the standard parallel port. This > is fine if you can dedicate your computer to every development project. > What if you need more than one BDM cable that requires a standard > parallel > port. Then you have to use an A/B switch but if your pod is powered you > can damage the emulator pod or the computer if you forget to power off > between changes of port. > > Rod Niner > . > > > Bob Furber <> > 01/09/2003 12:57 PM > Please respond to 68HC12 > To: > cc: > Subject: RE: [68HC12] M68KIT912DP256 > Hi Don, > > > From reading these postings, one can get the impression > > there is only one > > BDM emulator available for the HC12/HCS12, and it has many > > problems, and > > there is nothing to do about it. > > Actually, I believe that there are very few problems with > the P&E debuger and debug cable and and even fewer that > don't have a simple, inexpensive solutions. We hear about > these problems because ..well, that is what this list is > for. > > > They don't have any of the reported > > problems here. > > Nohau is selling a BDM for $1990, plugging to either USB, > LPT > > port or a > > dedicated ISA card. Other vendors exist as well. Yes, it > is > > more expensive > > than the P&E, but on the other hand it will save some of > your > > frustration, > > and will return its investment by saving the time you mess > up > > with problems. > > You make some good points. The Nohau emulator may indeed > offer many advantages over the P&E debugger ..for a price. > Notwithstanding, many users, including myself, find that the > P&E debugger/cable offers very good value. Some people drink > beer, and some can afford champaigne. > > It would be interesting to hear about users experiences with > other debuggers and BDM modules. Maybe us beer drinkers > should consider coolers, or even champaigne. > > Bfn, > > Bob Furber > > __________________________________________________________ > > Connect your micro to the internet the easy way > www.microcommander.com > > Microcontroller with an obscenity of I/O & features > ..in a small footprint www.steroidmicros.com > __________________________________________________________ > > -------------------- > > ">http://docs.yahoo.com/info/terms/ > > -------------------- > > ">http://docs.yahoo.com/info/terms/>. |
|
M68KIT912DP256
Started by ●January 7, 2003
Reply by ●January 12, 20032003-01-12
Reply by ●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 ----------- |
|
Reply by ●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 ●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 ●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 ●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 ●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 ●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 ●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 ●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/ |
|