Debuging with P&E USB MULTILINK & Codewarrior 3

Started by ra January 22, 2004
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
Jordi Costa wrote:

>
> In True-Time Simulator & Real Time Debugger, open ICD-12,
> Communication,
> Special Setup tab and check Set CLKSW bit in BDM.....
> Even that, tracing is sometimes lost when clock frequency is changed.
>
> Jordi Costa





>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.

Hi, you must set RSBCK bit in COPCTL register.

Mariusz



Hello Robert.

We will provide this feature for sure in the next release.
Meanwhile, some modules like the ECT timer (DP256) can be freezed when
stepping.
Freeze mode can be seen as "when halted in BDM".

For example, set the TSFRZ bit in TSCR1 register.

TSFRZ Timer and Modulus Counter Stop While in Freeze Mode
0 = Allows the timer and modulus counter to continue running while in
freeze mode.
1 = Disables the timer and modulus counter whenever the MCU is in freeze
mode. This is useful
for emulation.

Several chip modules have this feature. This can easily be used to avoid
getting interrupt flags raised while the CPU is BDM stopped.

Regards,
Gilles
At 10:23 AM 1/22/2004, you wrote:
>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 >
>Jordi Costa wrote:
>
> >
> > In True-Time Simulator & Real Time Debugger, open ICD-12,
> > Communication,
> > Special Setup tab and check Set CLKSW bit in BDM.....
> > Even that, tracing is sometimes lost when clock frequency is changed.
> >
> > Jordi Costa >--------------------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 >





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
Jordi Costa wrote:

>
> In True-Time Simulator & Real Time Debugger, open ICD-12,
> Communication,
> Special Setup tab and check Set CLKSW bit in BDM.....
> Even that, tracing is sometimes lost when clock frequency is changed.
>
> Jordi Costa


--------------------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 This e-mail and any files transmitted with it ( Message ) are confidential and may contain privileged information.
This Message is intended solely for the addressee(s). If you have received this Message in error, please inform us promptly by reply e-mail then delete the Message and destroy any printed copy of it.
Any unauthorized use, review, retransmission, dissemination, distribution, printing or copying of this Message or any part thereof is strictly prohibited.
E-mails are susceptible to alteration. Neither Perry Slingsby Systems nor any of its subsidiaries and affiliates shall be liable for the Message if altered, changed or falsified



Hi Steve and Thanks!

With the ICD-12, you can do exactly the same in the Register window. It is
definitely the simplest way. The feature that we will provide in the future
is setting the I bit automatically (on checkbox option) while stepping to
skip maskable interrupts.

Regards,
Gilles At 02:37 PM 1/22/2004, you wrote:

>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 >
>Jordi Costa wrote:
>
> >
> > In True-Time Simulator & Real Time Debugger, open ICD-12,
> > Communication,
> > Special Setup tab and check Set CLKSW bit in BDM.....
> > Even that, tracing is sometimes lost when clock frequency is changed.
> >
> > Jordi Costa >--------------------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 >This e-mail and any files transmitted with it ( Message ) are
>confidential and may contain privileged information.
>This Message is intended solely for the addressee(s). If you have received
>this Message in error, please inform us promptly by reply e-mail then
>delete the Message and destroy any printed copy of it.
>Any unauthorized use, review, retransmission, dissemination, distribution,
>printing or copying of this Message or any part thereof is strictly prohibited.
>E-mails are susceptible to alteration. Neither Perry Slingsby Systems nor
>any of its subsidiaries and affiliates shall be liable for the Message if
>altered, changed or falsified
>
>--------------------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 >





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



Hello Gilles

What would be nice is if the interrupt routines could still be allowed
to function, but the stepping mechanism would be able to let the mcu
run until it actually reaches the next statement in the "foreground"
routine. That way the tasks of the interrupt routine can still play
their part to enable a more accurate debugging.

Thanks for your help!
Robert

>
> Hi Steve and Thanks!
>
> With the ICD-12, you can do exactly the same in the Register window.
> It is
> definitely the simplest way. The feature that we will provide in the
> future
> is setting the I bit automatically (on checkbox option) while stepping
> to
> skip maskable interrupts.
>
> Regards,
> Gilles > At 02:37 PM 1/22/2004, you wrote:
>
>> 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




Gilles:

I really like the feature of disabling the interrupts automatically when stepping or when a breakpoint is hit. In one of my applications I have a hardware IRQ hitting very regularly and I have to disable irq's manually each time I want to single step. Keep up the good work and the good ideas !!!

Steve Dillier
HighPoint Technology
----- Original Message -----
From: Gilles Blanquin
To:
Sent: Thursday, January 22, 2004 8:03 AM
Subject: RE: [68HC12] Debuging with P&E USB MULTILINK & Codewarrior 3 Hi Steve and Thanks!

With the ICD-12, you can do exactly the same in the Register window. It is
definitely the simplest way. The feature that we will provide in the future
is setting the I bit automatically (on checkbox option) while stepping to
skip maskable interrupts.

Regards,
Gilles At 02:37 PM 1/22/2004, you wrote:

>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 >
>Jordi Costa wrote:
>
> >
> > In True-Time Simulator & Real Time Debugger, open ICD-12,
> > Communication,
> > Special Setup tab and check Set CLKSW bit in BDM.....
> > Even that, tracing is sometimes lost when clock frequency is changed.
> >
> > Jordi Costa >--------------------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 >This e-mail and any files transmitted with it ( Message ) are
>confidential and may contain privileged information.
>This Message is intended solely for the addressee(s). If you have received
>this Message in error, please inform us promptly by reply e-mail then
>delete the Message and destroy any printed copy of it.
>Any unauthorized use, review, retransmission, dissemination, distribution,
>printing or copying of this Message or any part thereof is strictly prohibited.
>E-mails are susceptible to alteration. Neither Perry Slingsby Systems nor
>any of its subsidiaries and affiliates shall be liable for the Message if
>altered, changed or falsified
>
>--------------------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 >
--------------------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




I believe that having a checkbox feature would provide the best of both
worlds so that you could have ints completely shut down, or running in the
background - having a checkbox for each INT source to enable/disable on
single step would be heaven <g>. Although I agree with Robert that most of
the time I wish that the INTs could run as I step through the foreground
code to keep timers, etc in sync with foreground execution progress.

-----Original Message-----
From: ra [mailto:]
Sent: Thursday, January 22, 2004 9:11 AM
To:
Subject: Re: [68HC12] Debuging with P&E USB MULTILINK & Codewarrior 3 Hello Gilles

What would be nice is if the interrupt routines could still be allowed
to function, but the stepping mechanism would be able to let the mcu
run until it actually reaches the next statement in the "foreground"
routine. That way the tasks of the interrupt routine can still play
their part to enable a more accurate debugging.

Thanks for your help!
Robert

>
> Hi Steve and Thanks!
>
> With the ICD-12, you can do exactly the same in the Register window.
> It is
> definitely the simplest way. The feature that we will provide in the
> future
> is setting the I bit automatically (on checkbox option) while stepping
> to
> skip maskable interrupts.
>
> Regards,
> Gilles > At 02:37 PM 1/22/2004, you wrote:
>
>> 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
This e-mail and any files transmitted with it ( Message ) are confidential and may contain privileged information.
This Message is intended solely for the addressee(s). If you have received this Message in error, please inform us promptly by reply e-mail then delete the Message and destroy any printed copy of it.
Any unauthorized use, review, retransmission, dissemination, distribution, printing or copying of this Message or any part thereof is strictly prohibited.
E-mails are susceptible to alteration. Neither Perry Slingsby Systems nor any of its subsidiaries and affiliates shall be liable for the Message if altered, changed or falsified




Thanks all for your encouragements and feature extension hints.

Regards,
Gilles At 03:53 PM 1/22/2004, you wrote:

>I believe that having a checkbox feature would provide the best of both
>worlds so that you could have ints completely shut down, or running in the
>background - having a checkbox for each INT source to enable/disable on
>single step would be heaven <g>. Although I agree with Robert that most of
>the time I wish that the INTs could run as I step through the foreground
>code to keep timers, etc in sync with foreground execution progress.
>
>-----Original Message-----
>From: ra [mailto:]
>Sent: Thursday, January 22, 2004 9:11 AM
>To:
>Subject: Re: [68HC12] Debuging with P&E USB MULTILINK & Codewarrior 3 >Hello Gilles
>
>What would be nice is if the interrupt routines could still be allowed
>to function, but the stepping mechanism would be able to let the mcu
>run until it actually reaches the next statement in the "foreground"
>routine. That way the tasks of the interrupt routine can still play
>their part to enable a more accurate debugging.
>
>Thanks for your help!
>Robert
>
> >
> > Hi Steve and Thanks!
> >
> > With the ICD-12, you can do exactly the same in the Register window.
> > It is
> > definitely the simplest way. The feature that we will provide in the
> > future
> > is setting the I bit automatically (on checkbox option) while stepping
> > to
> > skip maskable interrupts.
> >
> > Regards,
> > Gilles
> >
> >
> > At 02:37 PM 1/22/2004, you wrote:
> >
> >> 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 >
>This e-mail and any files transmitted with it ( Message ) are
>confidential and may contain privileged information.
>This Message is intended solely for the addressee(s). If you have received
>this Message in error, please inform us promptly by reply e-mail then
>delete the Message and destroy any printed copy of it.
>Any unauthorized use, review, retransmission, dissemination, distribution,
>printing or copying of this Message or any part thereof is strictly prohibited.
>E-mails are susceptible to alteration. Neither Perry Slingsby Systems nor
>any of its subsidiaries and affiliates shall be liable for the Message if
>altered, changed or falsified
>
>--------------------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 >