Motorola's claims for BDM before we had it commercially 10+ years ago was that because of pin densities emulators would not be practical. Since then true plugging into a target has either been avoided by fitting socket all around the processor on a prototype or achieved with very expensive adapters. Anyway to continue Motorola's claims were wonderful and I expect MC683xx or whatever the first was achieved them, they were certainly achieve with HC16. The pll on the HC16 is quite tricky with lots of divide and multiply bits to configure. Anyway I sat with my frequency counter P&E cable and ICD16W, and tried all sorts of things, and the BDM held on throughout. If you can do that with HC16 it should be achievable with other micros. The BDM connector has two spare pins so take an ungated E clock, or something from the processor if you have to and make the BDM work. The only thing an emulator usually beats BDM on is timing analysis, I guess. For those new to it, emulators are very friendly easy and allow you to vero board bits and try them one by one. An EVB is a good starting point for anyone, I then go strait to production design or as near as. I read the comment about how noice deals with single stepping, Cosmic Zap can work that way. Inadvertently stepping it to interrupts and library functions, and having to stop interrupts is really uncivilised, but the ability to step it to interrupts and library functions if you want to is handy. 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: John Hartman (NoICE) To: Sent: Friday, January 23, 2004 2:43 AM Subject: Re: [68HC12] Debuging with P&E USB MULTILINK & Codewarrior 3 >One of the many advantages of a full HCS12 emulator is that it allows >testing all the code in all clock settings (and all operating conditions) >with no limitations. The full emulator (automatically) keeps working >through PLL speed-changes (even very frequent and intensive speed changes), >through clock-loss limp-home mode, through all STOP and WAIT power down >modes, and through COP-Watchdog and external Resets. Of course, if Motorola would actually fix the bug, BDM would stay at the crystal rate like the datasheet says that it should and the problem wouldn't be a problem. When I first heard about this bug two years ago I assumed that it was an early mask thing, but there seems to be no plan to fix it, at least on the Dx256 etc. Some of the other MC9S12 parts (like the C32) seem to be OK. >In regard to the topic of the debugger offering the option to mask >interrupts automatically on single-steps (so you don't land in an interrupt >service routine every time you single-step): The Nohau BDM and >Full-Emulator have this check-box option for years now. Another method is not to use the BDM's single-step. NoICE automatically sets (and later removes) a breakpoint on the address after then next instruction (two breakpoints in case of a conditional branch). It looks like single-step to the user, the interrupts happen as they like, and the program stops at the breakpoint. Should you happen to WANT to step into the interrupt, an instruction-step command is also available. Full feature, less-than-full price... Best regards, John Hartman NoICE Debugging Tools http://www.noicedebugger.com

>One of the many advantages of a full HCS12 emulator is that it allows >testing all the code in all clock settings (and all operating conditions) >with no limitations. The full emulator (automatically) keeps working >through PLL speed-changes (even very frequent and intensive speed changes), >through clock-loss limp-home mode, through all STOP and WAIT power down >modes, and through COP-Watchdog and external Resets. Of course, if Motorola would actually fix the bug, BDM would stay at the crystal rate like the datasheet says that it should and the problem wouldn't be a problem. When I first heard about this bug two years ago I assumed that it was an early mask thing, but there seems to be no plan to fix it, at least on the Dx256 etc. Some of the other MC9S12 parts (like the C32) seem to be OK. >In regard to the topic of the debugger offering the option to mask >interrupts automatically on single-steps (so you don't land in an interrupt >service routine every time you single-step): The Nohau BDM and >Full-Emulator have this check-box option for years now. Another method is not to use the BDM's single-step. NoICE automatically sets (and later removes) a breakpoint on the address after then next instruction (two breakpoints in case of a conditional branch). It looks like single-step to the user, the interrupts happen as they like, and the program stops at the breakpoint. Should you happen to WANT to step into the interrupt, an instruction-step command is also available. Full feature, less-than-full price... Best regards, John Hartman NoICE Debugging Tools http://www.noicedebugger.com

Andrew and all, One of the many advantages of a full HCS12 emulator is that it allows testing all the code in all clock settings (and all operating conditions) with no limitations. The full emulator (automatically) keeps working through PLL speed-changes (even very frequent and intensive speed changes), through clock-loss limp-home mode, through all STOP and WAIT power down modes, and through COP-Watchdog and external Resets. HC12 BDMs heavily suffer in these areas, because of the nature of the BDM interface. In regard to the topic of the debugger offering the option to mask interrupts automatically on single-steps (so you don't land in an interrupt service routine every time you single-step): The Nohau BDM and Full-Emulator have this check-box option for years now. These are the kind of advantages that you usually get with the higher-end debuggers and emulators. It's true - they usually have also a higher price. This is the trade off between lower end debuggers, and higher end debuggers and emulators. Hope this helps, Doron Nohau Corporation HC12 In-Circuit Emulators www.nohau.com/emul12pc.html At 14:03 22/01/2004 +0000, you wrote: >Many BDM debuggers work the other way so you don't step into interrupts or >code that there are no symbols for (e.g. library functions). > >It's rather a shame that HCS12 BDM, like PowerPC is not as robust as HC16 >which I have found fault less in the past. Consequently you have a bugs in >your code and if those bugs affect the clock or something you can't >reliably debug your code. So what did you want a debugger for? >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: Killingsworth, Steve > To: > Sent: Thursday, January 22, 2004 1:37 PM > Subject: RE: [68HC12] Debuging with P&E USB MULTILINK & Codewarrior 3 > > I am not sure about the ICD-12, however, with my Mot-SDI I just clear the I > bit in the CCR register by double-clicking it. When I want interrupts back > on, I double-click it again. > > Hope this helps. > > -----Original Message----- > From: ra [mailto:] > Sent: Thursday, January 22, 2004 4:24 AM > To: > Subject: [68HC12] Debuging with P&E USB MULTILINK & Codewarrior 3 > Hello, > > While talking about P&E USB MULTILINK and debugging with ICD-12 in > Codewarrior 3, would someone know a trick to facilitate stepping > through "main" code without landing in interrupt driven background > routines? (In C) > For example, if there is a periodic interrupt for a implementing a real > time clock, then there should be a way to single-step in some > foreground routine and having the True-Time Simulator & Real Time > Debugger know that the next step should be in the same foreground > routine and not in the interrupt task. > The only work-around I found so far is to use "Run to cursor" on a > subsequent statement, but this doesn't work when faced with a > conditional branch. > > Many thanks! > Robert Imhoff >--------------------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 >

Thanks all for your encouragements and feature extension hints. Regards, Gilles At 03:53 PM 1/22/2004, you wrote: >I believe that having a checkbox feature would provide the best of both >worlds so that you could have ints completely shut down, or running in the >background - having a checkbox for each INT source to enable/disable on >single step would be heaven <g>. Although I agree with Robert that most of >the time I wish that the INTs could run as I step through the foreground >code to keep timers, etc in sync with foreground execution progress. > >-----Original Message----- >From: ra [mailto:] >Sent: Thursday, January 22, 2004 9:11 AM >To: >Subject: Re: [68HC12] Debuging with P&E USB MULTILINK & Codewarrior 3 >Hello Gilles > >What would be nice is if the interrupt routines could still be allowed >to function, but the stepping mechanism would be able to let the mcu >run until it actually reaches the next statement in the "foreground" >routine. That way the tasks of the interrupt routine can still play >their part to enable a more accurate debugging. > >Thanks for your help! >Robert > > > > > Hi Steve and Thanks! > > > > With the ICD-12, you can do exactly the same in the Register window. > > It is > > definitely the simplest way. The feature that we will provide in the > > future > > is setting the I bit automatically (on checkbox option) while stepping > > to > > skip maskable interrupts. > > > > Regards, > > Gilles > > > > > > At 02:37 PM 1/22/2004, you wrote: > > > >> I am not sure about the ICD-12, however, with my Mot-SDI I just clear > >> the I > >> bit in the CCR register by double-clicking it. When I want > >> interrupts back > >> on, I double-click it again. > >> > >> Hope this helps. > >> > >> -----Original Message----- > >> From: ra [mailto:] > >> Sent: Thursday, January 22, 2004 4:24 AM > >> To: > >> Subject: [68HC12] Debuging with P&E USB MULTILINK & Codewarrior 3 > >> > >> > >> Hello, > >> > >> While talking about P&E USB MULTILINK and debugging with ICD-12 in > >> Codewarrior 3, would someone know a trick to facilitate stepping > >> through "main" code without landing in interrupt driven background > >> routines? (In C) > >> For example, if there is a periodic interrupt for a implementing a > >> real > >> time clock, then there should be a way to single-step in some > >> foreground routine and having the True-Time Simulator & Real Time > >> Debugger know that the next step should be in the same foreground > >> routine and not in the interrupt task. > >> The only work-around I found so far is to use "Run to cursor" on a > >> subsequent statement, but this doesn't work when faced with a > >> conditional branch. > >> > >> Many thanks! > >> Robert Imhoff >--------------------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 > >This e-mail and any files transmitted with it ( Message ) are >confidential and may contain privileged information. >This Message is intended solely for the addressee(s). If you have received >this Message in error, please inform us promptly by reply e-mail then >delete the Message and destroy any printed copy of it. >Any unauthorized use, review, retransmission, dissemination, distribution, >printing or copying of this Message or any part thereof is strictly prohibited. >E-mails are susceptible to alteration. Neither Perry Slingsby Systems nor >any of its subsidiaries and affiliates shall be liable for the Message if >altered, changed or falsified > >--------------------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 >

I believe that having a checkbox feature would provide the best of both worlds so that you could have ints completely shut down, or running in the background - having a checkbox for each INT source to enable/disable on single step would be heaven <g>. Although I agree with Robert that most of the time I wish that the INTs could run as I step through the foreground code to keep timers, etc in sync with foreground execution progress. -----Original Message----- From: ra [mailto:] Sent: Thursday, January 22, 2004 9:11 AM To: Subject: Re: [68HC12] Debuging with P&E USB MULTILINK & Codewarrior 3 Hello Gilles What would be nice is if the interrupt routines could still be allowed to function, but the stepping mechanism would be able to let the mcu run until it actually reaches the next statement in the "foreground" routine. That way the tasks of the interrupt routine can still play their part to enable a more accurate debugging. Thanks for your help! Robert > > Hi Steve and Thanks! > > With the ICD-12, you can do exactly the same in the Register window. > It is > definitely the simplest way. The feature that we will provide in the > future > is setting the I bit automatically (on checkbox option) while stepping > to > skip maskable interrupts. > > Regards, > Gilles > At 02:37 PM 1/22/2004, you wrote: > >> I am not sure about the ICD-12, however, with my Mot-SDI I just clear >> the I >> bit in the CCR register by double-clicking it. When I want >> interrupts back >> on, I double-click it again. >> >> Hope this helps. >> >> -----Original Message----- >> From: ra [mailto:] >> Sent: Thursday, January 22, 2004 4:24 AM >> To: >> Subject: [68HC12] Debuging with P&E USB MULTILINK & Codewarrior 3 >> >> >> Hello, >> >> While talking about P&E USB MULTILINK and debugging with ICD-12 in >> Codewarrior 3, would someone know a trick to facilitate stepping >> through "main" code without landing in interrupt driven background >> routines? (In C) >> For example, if there is a periodic interrupt for a implementing a >> real >> time clock, then there should be a way to single-step in some >> foreground routine and having the True-Time Simulator & Real Time >> Debugger know that the next step should be in the same foreground >> routine and not in the interrupt task. >> The only work-around I found so far is to use "Run to cursor" on a >> subsequent statement, but this doesn't work when faced with a >> conditional branch. >> >> Many thanks! >> Robert Imhoff --------------------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 This e-mail and any files transmitted with it ( Message ) are confidential and may contain privileged information. This Message is intended solely for the addressee(s). If you have received this Message in error, please inform us promptly by reply e-mail then delete the Message and destroy any printed copy of it. Any unauthorized use, review, retransmission, dissemination, distribution, printing or copying of this Message or any part thereof is strictly prohibited. E-mails are susceptible to alteration. Neither Perry Slingsby Systems nor any of its subsidiaries and affiliates shall be liable for the Message if altered, changed or falsified

Gilles: I really like the feature of disabling the interrupts automatically when stepping or when a breakpoint is hit. In one of my applications I have a hardware IRQ hitting very regularly and I have to disable irq's manually each time I want to single step. Keep up the good work and the good ideas !!! Steve Dillier HighPoint Technology ----- Original Message ----- From: Gilles Blanquin To: Sent: Thursday, January 22, 2004 8:03 AM Subject: RE: [68HC12] Debuging with P&E USB MULTILINK & Codewarrior 3 Hi Steve and Thanks! With the ICD-12, you can do exactly the same in the Register window. It is definitely the simplest way. The feature that we will provide in the future is setting the I bit automatically (on checkbox option) while stepping to skip maskable interrupts. Regards, Gilles At 02:37 PM 1/22/2004, you wrote: >I am not sure about the ICD-12, however, with my Mot-SDI I just clear the I >bit in the CCR register by double-clicking it. When I want interrupts back >on, I double-click it again. > >Hope this helps. > >-----Original Message----- >From: ra [mailto:] >Sent: Thursday, January 22, 2004 4:24 AM >To: >Subject: [68HC12] Debuging with P&E USB MULTILINK & Codewarrior 3 >Hello, > >While talking about P&E USB MULTILINK and debugging with ICD-12 in >Codewarrior 3, would someone know a trick to facilitate stepping >through "main" code without landing in interrupt driven background >routines? (In C) >For example, if there is a periodic interrupt for a implementing a real >time clock, then there should be a way to single-step in some >foreground routine and having the True-Time Simulator & Real Time >Debugger know that the next step should be in the same foreground >routine and not in the interrupt task. >The only work-around I found so far is to use "Run to cursor" on a >subsequent statement, but this doesn't work when faced with a >conditional branch. > >Many thanks! >Robert Imhoff > >Jordi Costa wrote: > > > > > In True-Time Simulator & Real Time Debugger, open ICD-12, > > Communication, > > Special Setup tab and check Set CLKSW bit in BDM..... > > Even that, tracing is sometimes lost when clock frequency is changed. > > > > Jordi Costa >--------------------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 >This e-mail and any files transmitted with it ( Message ) are >confidential and may contain privileged information. >This Message is intended solely for the addressee(s). If you have received >this Message in error, please inform us promptly by reply e-mail then >delete the Message and destroy any printed copy of it. >Any unauthorized use, review, retransmission, dissemination, distribution, >printing or copying of this Message or any part thereof is strictly prohibited. >E-mails are susceptible to alteration. Neither Perry Slingsby Systems nor >any of its subsidiaries and affiliates shall be liable for the Message if >altered, changed or falsified > >--------------------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 > --------------------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 a.. To

Hello Gilles What would be nice is if the interrupt routines could still be allowed to function, but the stepping mechanism would be able to let the mcu run until it actually reaches the next statement in the "foreground" routine. That way the tasks of the interrupt routine can still play their part to enable a more accurate debugging. Thanks for your help! Robert > > Hi Steve and Thanks! > > With the ICD-12, you can do exactly the same in the Register window. > It is > definitely the simplest way. The feature that we will provide in the > future > is setting the I bit automatically (on checkbox option) while stepping > to > skip maskable interrupts. > > Regards, > Gilles > At 02:37 PM 1/22/2004, you wrote: > >> I am not sure about the ICD-12, however, with my Mot-SDI I just clear >> the I >> bit in the CCR register by double-clicking it. When I want >> interrupts back >> on, I double-click it again. >> >> Hope this helps. >> >> -----Original Message----- >> From: ra [mailto:] >> Sent: Thursday, January 22, 2004 4:24 AM >> To: >> Subject: [68HC12] Debuging with P&E USB MULTILINK & Codewarrior 3 >> >> >> Hello, >> >> While talking about P&E USB MULTILINK and debugging with ICD-12 in >> Codewarrior 3, would someone know a trick to facilitate stepping >> through "main" code without landing in interrupt driven background >> routines? (In C) >> For example, if there is a periodic interrupt for a implementing a >> real >> time clock, then there should be a way to single-step in some >> foreground routine and having the True-Time Simulator & Real Time >> Debugger know that the next step should be in the same foreground >> routine and not in the interrupt task. >> The only work-around I found so far is to use "Run to cursor" on a >> subsequent statement, but this doesn't work when faced with a >> conditional branch. >> >> Many thanks! >> Robert Imhoff

Hi Steve and Thanks! With the ICD-12, you can do exactly the same in the Register window. It is definitely the simplest way. The feature that we will provide in the future is setting the I bit automatically (on checkbox option) while stepping to skip maskable interrupts. Regards, Gilles At 02:37 PM 1/22/2004, you wrote: >I am not sure about the ICD-12, however, with my Mot-SDI I just clear the I >bit in the CCR register by double-clicking it. When I want interrupts back >on, I double-click it again. > >Hope this helps. > >-----Original Message----- >From: ra [mailto:] >Sent: Thursday, January 22, 2004 4:24 AM >To: >Subject: [68HC12] Debuging with P&E USB MULTILINK & Codewarrior 3 >Hello, > >While talking about P&E USB MULTILINK and debugging with ICD-12 in >Codewarrior 3, would someone know a trick to facilitate stepping >through "main" code without landing in interrupt driven background >routines? (In C) >For example, if there is a periodic interrupt for a implementing a real >time clock, then there should be a way to single-step in some >foreground routine and having the True-Time Simulator & Real Time >Debugger know that the next step should be in the same foreground >routine and not in the interrupt task. >The only work-around I found so far is to use "Run to cursor" on a >subsequent statement, but this doesn't work when faced with a >conditional branch. > >Many thanks! >Robert Imhoff > >Jordi Costa wrote: > > > > > In True-Time Simulator & Real Time Debugger, open ICD-12, > > Communication, > > Special Setup tab and check Set CLKSW bit in BDM..... > > Even that, tracing is sometimes lost when clock frequency is changed. > > > > Jordi Costa >--------------------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 >This e-mail and any files transmitted with it ( Message ) are >confidential and may contain privileged information. >This Message is intended solely for the addressee(s). If you have received >this Message in error, please inform us promptly by reply e-mail then >delete the Message and destroy any printed copy of it. >Any unauthorized use, review, retransmission, dissemination, distribution, >printing or copying of this Message or any part thereof is strictly prohibited. >E-mails are susceptible to alteration. Neither Perry Slingsby Systems nor >any of its subsidiaries and affiliates shall be liable for the Message if >altered, changed or falsified > >--------------------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 >

Many BDM debuggers work the other way so you don't step into interrupts or code that there are no symbols for (e.g. library functions). It's rather a shame that HCS12 BDM, like PowerPC is not as robust as HC16 which I have found fault less in the past. Consequently you have a bugs in your code and if those bugs affect the clock or something you can't reliably debug your code. So what did you want a debugger for? 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: Killingsworth, Steve To: Sent: Thursday, January 22, 2004 1:37 PM Subject: RE: [68HC12] Debuging with P&E USB MULTILINK & Codewarrior 3 I am not sure about the ICD-12, however, with my Mot-SDI I just clear the I bit in the CCR register by double-clicking it. When I want interrupts back on, I double-click it again. Hope this helps. -----Original Message----- From: ra [mailto:] Sent: Thursday, January 22, 2004 4:24 AM To: Subject: [68HC12] Debuging with P&E USB MULTILINK & Codewarrior 3 Hello, While talking about P&E USB MULTILINK and debugging with ICD-12 in Codewarrior 3, would someone know a trick to facilitate stepping through "main" code without landing in interrupt driven background routines? (In C) For example, if there is a periodic interrupt for a implementing a real time clock, then there should be a way to single-step in some foreground routine and having the True-Time Simulator & Real Time Debugger know that the next step should be in the same foreground routine and not in the interrupt task. The only work-around I found so far is to use "Run to cursor" on a subsequent statement, but this doesn't work when faced with a conditional branch. Many thanks! Robert Imhoff

I am not sure about the ICD-12, however, with my Mot-SDI I just clear the I bit in the CCR register by double-clicking it. When I want interrupts back on, I double-click it again. Hope this helps. -----Original Message----- From: ra [mailto:] Sent: Thursday, January 22, 2004 4:24 AM To: Subject: [68HC12] Debuging with P&E USB MULTILINK & Codewarrior 3 Hello, While talking about P&E USB MULTILINK and debugging with ICD-12 in Codewarrior 3, would someone know a trick to facilitate stepping through "main" code without landing in interrupt driven background routines? (In C) For example, if there is a periodic interrupt for a implementing a real time clock, then there should be a way to single-step in some foreground routine and having the True-Time Simulator & Real Time Debugger know that the next step should be in the same foreground routine and not in the interrupt task. The only work-around I found so far is to use "Run to cursor" on a subsequent statement, but this doesn't work when faced with a conditional branch. Many thanks! Robert Imhoff Jordi Costa wrote: > > In True-Time Simulator & Real Time Debugger, open ICD-12, > Communication, > Special Setup tab and check Set CLKSW bit in BDM..... > Even that, tracing is sometimes lost when clock frequency is changed. > > Jordi Costa --------------------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 This e-mail and any files transmitted with it ( Message ) are confidential and may contain privileged information. This Message is intended solely for the addressee(s). If you have received this Message in error, please inform us promptly by reply e-mail then delete the Message and destroy any printed copy of it. Any unauthorized use, review, retransmission, dissemination, distribution, printing or copying of this Message or any part thereof is strictly prohibited. E-mails are susceptible to alteration. Neither Perry Slingsby Systems nor any of its subsidiaries and affiliates shall be liable for the Message if altered, changed or falsified