Debugging with CW5.2 and MC9S12DG256

gerritbarrere · ‎08-02-2017

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 (12.4.0.0).

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?

kef2 · ‎08-09-2017

Hi Gerrit,

As you may guess, post reset register inspection won't reveal anything useful, most of them except CRGFLG PORF bit will be reset.

While operating in special single chip mode (default BDM debugger mode), you could execute BGND instruction, which would work as software breakpoint. But once reset happens with BKGD pin properly pulled high, BGND instruction turns into a lot of NOPs instruction and won't help you. No, it's not possible in normal operating mode to give control to debugger by means of S12 software.

For debugging purposes you can enter forever loop in your reset handlers, and then hodplug BDM debugger. Hotplug doesn't mean just plugging BDM connector, it's debugger mode, in which it isn't resetting target into special mode and tries to connect to target operating in normal single chip mode. After connect you would need to hit pause button to stop target at your forever loop.

Regards,

Edward

View solution in original post

gerritbarrere · ‎08-02-2017

I should add that breakpoints in and before main() work just fine when I reset from within the debugger, ("reset target") but when an actual system reset occurs (due to watchdog timeout, etc.) the breakpoint is ignored.

kef2 · ‎08-02-2017

Reset does reset all hardware, including hardware breakpoints. You can't count on them debugging sudden resets. Even worse, traditional BDM debugging uses special single chip mode, which is entered pulling BKGD pin low and then pulsing RESET pin. Once your sudden reset occurs, target resets to normal single chip mode...

Regards,

Edward

gerritbarrere · ‎08-08-2017

Thank you for the reply, Edward. I have been away from the office a few days.

I see now where there are reset states for several of the BKP module registers shown in the CPU Core User's Guide, so the BKP module is indeed disabled on reset.

How is it that I can "reset target" from the debugger and breakpoints work, though? External resets (like the watchdog) don't see breakpoints, but resetting from the debugger does.

kef2 · ‎08-08-2017

Hi,

Simple. Debugger reinitializes BKP after its own generated reset.

Edward

gerritbarrere · ‎08-09-2017

OK, that makes sense. Do you know if I can put something in my reset code to cause the BDM debugger to take control? That way I could examine memory and registers after an external reset. I have tried setting the ENBDM bit and then executing a BGND instruction, and that doesn't do it.

kef2 · ‎08-09-2017

Hi Gerrit,

As you may guess, post reset register inspection won't reveal anything useful, most of them except CRGFLG PORF bit will be reset.

While operating in special single chip mode (default BDM debugger mode), you could execute BGND instruction, which would work as software breakpoint. But once reset happens with BKGD pin properly pulled high, BGND instruction turns into a lot of NOPs instruction and won't help you. No, it's not possible in normal operating mode to give control to debugger by means of S12 software.

For debugging purposes you can enter forever loop in your reset handlers, and then hodplug BDM debugger. Hotplug doesn't mean just plugging BDM connector, it's debugger mode, in which it isn't resetting target into special mode and tries to connect to target operating in normal single chip mode. After connect you would need to hit pause button to stop target at your forever loop.

Regards,

Edward

gerritbarrere · ‎08-10-2017

Yes, you're right -- examining registers isn't very helpful, but I can at least look at memory.

The forever loop works. I can perform a hardware reset, then a 'halt' from the debugger and there I am at my loop. At that point I can examine memory. I can write "breadcrumb" values to a fixed memory location and start to figure out what was happening when my watchdog went off.

Thank you for your help!