AnsweredAssumed Answered

Debugging with CW5.2 and MC9S12DG256

Question asked by Gerrit Barrere on Aug 2, 2017
Latest reply on Aug 10, 2017 by Gerrit Barrere

I recently upgraded to CW 5.2 on Windows 10 for my 9S12DG256 project.  In order to get support for this processor I installed the patches from How-to Add missing derivatives to CodeWarrior Classic HCS12(X) 5.2 (Unofficial Method) .  I have rebuilt my project and can successfully load it to my target with the CW debugger (v6.1 build 10221).  I have tested it and it runs just fine.  I am using a new P&E Multilink Universal BDM debugger with the latest driver (


I am having trouble with erratic debugger behavior though.  I can set hardware breakpoints many different places in my code (located in paged flash) and they work just fine.  But breakpoints in main() or any place before it (to track down a spurious reset bug) don't work.  The breakpoints are skipped over, or the debugger crashes.


I am using HCS12MultilinkCyclonePro / Set Hardware BP "Automatic" mode, 22 bit breakpoint addresses, and BP module base address of 0x28. 


I know my bug is hitting main() because of other unique symptoms.  I have tried breaking many different places in and before main() and nothing in this area works.  I am not changing the base location of my registers, so my breakpoint module should always start at 0x28.  I have read TN113 from this site.


There is another erratic behavior too.  About every third time I "unsecure" my processor (HCS12MultilinkCyclonePro / Unsecure...) the debugger crashes, unsecure fails, and I can't access the processor with the debugger any longer.  If I run the P&E Unsecure12 utility v1.11 (from 2002) at this point it correctly unsecures the processor and I can start using the debugger again.  I am using a CLKDIV value of 28 decimal in the debugger 'unsecure' menu, which is appropriate for my MCU with an external clock of 4.192 MHz.


Can anyone help me get my debugger in good shape so I can reliably use it for breakpoints anywhere in my code and unsecuring when necessary?