Strange issue with register display in debugger

[PThomas]

Hey all... not sure if this is a problem with the BDM or with the debugger (or with me!) so I'll post at both sites.

I have a very simple app that is supposed to read data from one serial port at one speed, and send it out via the other at a different speed.  At this point it is all polling-based because I'm trying to test one character at a time.  The problem is that upon (or during) entry to the receive routine, the uC seems to simply hang.  I've seen similar "weird behavior" from time to time via the serial bootloader, but have not seen any since I moved to the BDM.

Target is a MC9S12DP256B, I'm using the "small" memory map (the program is probably a few hundred bytes, not counting any freescale template overhead), and in fact have been prototyping the design with an old Dragon12 board, which I've known to work on other projects.  I'm using CodeWarrior IDE 5.9.0, and debugger 6.1, with a PE Micro USB Multilink (USB-ML-12E) that has the latest firmware (5.81).

I do use the PLL as a clock due to serial speed, but the serial handling routines (except for the one it's hanging on) have all been used successfully in the past, and indeed I even used a test function on those that just outputs sequential serial data, and it did work for that.

Even though I turned interrupts off in the code, and the I flag corroborated this, I also set "ISRDISABLEDSTEP" just in case.

The disassembly in the debug window is as follows:
C127  JSR   0xC051
C12A  LEAX  2,SP
C12C  PSHX
C12D  LEAX  3,SP
C12F  PSHX
C130  LEAX  4,SP
C132  TFR   X,D
C134  JSR   0xC06C
...
C06C  PSHD   <---- hangs here

Clicking "assembly step" at C12A results in no apparent change, although clicking again results in it going to C12C, so presumably it's executing the instruction, but for whatever reason is not highlighted.

At C12D, a similar behavior, where it is never highlighted... however I noticed the PC is actually set to C12E, which shows no code!  Then C12F is never highlighted, but C130 and onward seems to work okay, until finally the branch is taken, where it jumps to C06C and hangs at the PSHD, no matter how many times I continue to press "step", etc.

I tried removing this from a function and putting it directly into the main code, and now it actually hangs somewhere back in my serial setup routine, which does nothing except set 3 SCI registers, with the same symptom: assembly steps do not "align" with actual code, ex: for setting SCI1BDL=26, C061 is LDAB #26, C063 is STAB 0xD1, but PC=C062 (!?!?).

I have done clean rebuilds to confirm the object code matches source, restarted the compiler & debugger to see if it was a resource issue... no dice.

Any help GREATLY appreciated!!

Thanks!

[Lundin]

An advise: you should have in mind that DP256B is very buggy on IC level. This is an old mask set which was full of hardware bugs in the SCI, among other things. I would strongly recommend using a later mask set, or otherwise read up on the erratas in detail.

This might not be the cause of your particular problem, but you should definitely have it in mind. You don't want to use the 'B' mask anyway, since Freescale has stopped selling it several years ago (I believe it can be bought from Rochester still).

[PatrickT]

Apologies for my lack of clarity, it is in fact a DP256C component, B is just the "target" chosen from the build list, in absence of a "C" component in the list.

I'm trying to figure out if the lack of response here is because it's something that's really obvious, or something that's really confusing.   In either case, I'm a little troubled that nobody has any ideas after almost a week both here and on PE Micro.  I'm kinda running out of ideas, and to some extent time.   Going to try to re-write it all in assembler and see if that sheds any light, meanwhile maybe it's time to submit a ticket on it and see if that gets me anywhere....

Thanks anyway for your suggestion!

[kef]

Not obvious, not confusing. Just no idea. 

Maybe it is an issue with WAIT mode. BDM communications don't work in WAIT mode.

Maybe it's a standard for S12D debugging issue when PLL is engaged.

Maybe disassembe window is simply not synchronized to PC. I mean if you right click in dasm window and enter Address from the middle of multibyte CPU instruction, you may see something stupid, but not real code.

etc.

[PatrickT]

Glad to know I'm not the only one.

Actually I think I found at least "most" of the issue... it appears I've run afoul of the known errata / "features" surrounding the use of the PLL.  I had omitted it from my description of the problem, since:

 * I've debugged with the PLL in numerous other applications without serious issue (although some "odd" behavior which this explains)

 * It hung several instructions after transferring to the PLL

 * The problem appeared present when "free running" -- not just in step mode

While re-writing it piece by piece in assembler, I omitted the PLL code and it appeared to work.  I confirmed this by commenting it out of the C code, and that also began to work.

I have not yet found the complete solution for getting the CodeWarrior debugger and PE Micro USB Multilink to deal with the PLL issue -- and would welcome the feedback if someone can shortcut my online quest -- but at least for this application, for now, I can debug at a slower rate until my final design (with higher clock) is ready for action.

Thanks for the responses!

[CrasyCat]

Hello

If you are looking for a way to be able to debug after you have changed the value of the  PLL in your application, check the box  "Set CLKSW bit in BDM control register (MC912 only)" .

This check box is available selecting "Multilink/CyclonePro" -> "Communication" menu entry and switching to "Special Setup" tab.

CrasyCat

[PatrickT]

Got it, thanks!!