At 07:17 PM 4/24/2004, you wrote:
>Here's the answers to your questions:
>
>1) MODA and MODB are tied low.
>2) I'm not enabling COP.
Hi Don.
Which derivative do you use? An MC9S12T64 would have the COP enabled even
in BDM.
Which CodeWarrior version for HC12 do you use?
>3) I don't think they are moving the I/O
block.
CodeWarrior Register block moves handling (since V2.0): On MC9S12
derivatives, the target interface automatically tracks (via BDM image)
device Registers block moves. For HC12 derivatives, the REGBLKADR command
can be used to specify the new location of the register block.
>4) ???
While stepping in the debugger, if there is a pending ISR, the next step
dives in the ISR. This can be avoided masking maskable interrupts. To do
this, simply click on the I bit in the Register window to set/clear this bit.
In latest CodeWarrior for HC(S)12 v3.1 : It is possible to disable maskable
interrupts while stepping, when checking the "Disable maskable ISR's
when
stepping" checkbox in "Communication"|"Special Setup"
dialog. This option
will also care about possible operations performed by the current
instruction vs. the I bit.
>5) Yes I'm enabling the PLL.
>
>I have a timer interrupt enabled that it jumps to repeatedly
>when single stepping. I was able to stop this behavior by
>setting the TSFRZ bit in TSCR1.
Yes, definitely a good way to freeze the timer while debugging and avoiding
falling in timer ISR's, and forgetting point "4)" here above.
>I'm using the parallel port BDM and I see that
there is a appnote
>regarding the fact that some parallel ports may not be able
>to drive the BDM without cutting a pin on a resistor network
>on the BDM. I was running the BDM using a pass-thru on
>another device so I connected directly to the parallel port and
>it is working a little better now but still jumps off and executes
>'BGND" instructions when single stepping. Also when this is
>happening, I'm seeing the message "Frequency change detected,
>reconnect using io_delay_cnt: "2" " in the command window.
If your OS is Windows XP, have a look on http://www.pemicro.com. The
"WINXP2.REG Utility" might be useful for the parallel cable.
>I have a USB BDM at my disposal also so I tried
this also. It works 100%
>better but still jumps off and executes the "BGND" instructions
>no and then. What are these?
It is not obvious that at this point, the cable reads correct data from the
chip. The debugger might returns bad info.
Correct that "Frequency change detected..." is displayed in the
Command
window when the PLL got engaged. But io_delay_cnt: "2" means that the
chip
bus frequency is around 33 MHz, rather fast for a bus speed max of 25 MHz
(specs).
Could you give more details about the Xtal/oscillator you use and your PLL
registers setup?
Does your code change the PLL only once after reset or several time?
Did you check the "Set CLKSW bit in BDM control register (MC9S12
only)"
option in the ICD-12 menu, Connect.../Communication dialog?
Regard,
Gilles
>Now I have another problem that's very
perplexing. I have a function
>declared as:
>
>void SPIMEMWrite(unsigned long Addr, byte *pBuf, unsigned long Len);
>
>I make a call like:
>
>SPIMEMWrite(0L, &Buffer[0], 16L);
>
>I put a breakpoint just inside the function and the arguments are not
correct.
>
>Addr = 1048592 // incorrect
>pBuf // correct
>Len = 1048592 // incorrect
>
>Any ideas?
>
> ----- Original Message -----
> From: John Hartman (NoICE)
> To:
> Sent: Friday, April 23, 2004 4:18 PM
> Subject: Re: [68HC12] BDM problems
>
> >I'm fairly new to using the HC12. The tools I'm using is
CodeWarrior
> >and the Multilink BDM. The BDM doesn't seem to be working
correctly
> >as a debugging tool. Breakpoints only seem to work sporadically and
> >when I try to single step the processor seems to jump off into
never,
> >never land. Am I doing something wrong or is the BDM pretty useless
> >as a debugger? Any ideas?
>
> BDM is very useful as a debugger, but it takes a bit of thought
>
> Several common possibilities for "sporadic" and "never never
land":
>
> 1) Are your MODA and MODB pins tied low? BDM only works reliably if the
> chip starts in Special Single Chip mode. You code (or your debugger) can
> change the mode after reset, but you need to start in Special Single
Chip
> so that the micro doesn't take off and start executing until you tell
> it to.
>
> 2) Does your code enable the COP? It is disabled when you come up in
> Special Single Chip. However, if you enable it and don't service it,
a
> reset will occur (duh). However, during this reset, the BGND line will
> probably NOT be low, so the chip will start in NORMAL Single Chip mode
> rather then Special Single Chip. So, BDM won't be enabled, and since
you
> got a reset, all your hardware breakpoints are gone.
>
> 3) I haven't used CodeWarrior, but if your code moves the I/O
register
> block, the hardware breakpoints move with it. Will CodeWarrior know
where
> to find them?
>
> 4) If CodeWarrior uses the BDM TRACE1 command for single-step (as
opposed
> to using automatic breakpoints), please be aware that if there is an
> interrupt pending (and there usually is if your program has been
> stopped in
> the debugger), TRACE1 will trace into the interrupt routine - after
> all, it
> is just tracing the "next instruction". Are you just that
"never never"
> isn't an interrupt routine?
>
> 5) Are you enabling the PLL? Some 9S12 chips (at least the the Axxx and
> Dxxx) have a bug that messes up BDM when you enable the PLL. Most
> debuggers have a work-around, but you may need to enable it.
>
> Best regards, John Hartman
>
> NoICE Debugging Tools
> http://www.noicedebugger.com
>
> --------------------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
>--------------------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
>
>
|