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 > |
|
Debuging with P&E USB MULTILINK & Codewarrior 3
Started by ●January 22, 2004
Reply by ●January 22, 20042004-01-22
Reply by ●January 22, 20042004-01-22
>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 |
Reply by ●January 23, 20042004-01-23
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 |