detecting the debugger?

Started by "James M. Knox" October 27, 2007
This may be a simple question, but I've just never needed to do it
before. Is there a way for the software (HCS processor, specifically
an S12A64 if that matters) to detect that the debugger BDM cable is
attached? I would like to maintain only one version, but the P&E BDM
debugger won't run across a switch from 4 MHz to 48 MHz. So I am
having to run at a maximum of 8 MHz with the BDM cable attached, then
switch to full speed when I am not debugging.

I know I could probably rig an unused discrete and jumper, but I
would rather not have to do that. So I'm hoping there is a status
bit in a register somewhere that says it is under BDM control.

tnx,

jmk

-----------
James M. Knox
TriSoft ph 512-385-0316
1300 Koenig Lane West fax 512-371-5716
Suite 200
Austin, Tx 78756 j...@trisoft.com
-----------
Hi,

usually we debug in special single chip mode and run in normal single chip
mode. MODE register should tell you what mode is your chip in.

Regards

Edward
----- Original Message -----
From: "James M. Knox"
To: <6...>
Sent: Saturday, October 27, 2007 22:42
Subject: [68HC12] detecting the debugger?
>
> This may be a simple question, but I've just never needed to do it
> before. Is there a way for the software (HCS processor, specifically
> an S12A64 if that matters) to detect that the debugger BDM cable is
> attached? I would like to maintain only one version, but the P&E BDM
> debugger won't run across a switch from 4 MHz to 48 MHz. So I am
> having to run at a maximum of 8 MHz with the BDM cable attached, then
> switch to full speed when I am not debugging.
>
> I know I could probably rig an unused discrete and jumper, but I
> would rather not have to do that. So I'm hoping there is a status
> bit in a register somewhere that says it is under BDM control.
>
> tnx,
>
> jmk
>
> -----------
> James M. Knox
> TriSoft ph 512-385-0316
> 1300 Koenig Lane West fax 512-371-5716
> Suite 200
> Austin, Tx 78756 j...@trisoft.com
> -----------
>
>This may be a simple question, but I've just never needed to do it
>before. Is there a way for the software (HCS processor, specifically
>an S12A64 if that matters) to detect that the debugger BDM cable is
>attached? I would like to maintain only one version, but the P&E BDM
>debugger won't run across a switch from 4 MHz to 48 MHz.

As Edward suggests the MODE register would let your software tell
whether it is being debugged.
Are you sure that the debugger can't be configured to deal with this?

(My apologies if you already know all of what follows)

Normally, one would want the CLKSW bit in the BDMSTATUS register to
be zero, so that BDM speed remains at crystal/2 whether the PLL is
enabled or not.

But some MC9S12 (the A256 and DP256 in particular) had/have a bug:
BDM Loses Sync when Using PLL at High Frequencies
When using the BDM constant clock source, i.e. CLKSW=0, with the PLL
engaged, PLLSEL=1, and the PLL multiplier greater than or equal to 2, the
BDM can lose communication with the host system.
Workaround Do not use the BDM constant clock source with the PLL engaged and a
multiplier greater than or equal to 2. Set CLKSW=1 before engaging the PLL.
The problem is that when you set CLKSW, then BDM speed follows the
bus speed, which causes trouble for the debugger.

My reading of FreeScale errata shows this on the A256 and DP256, but
not on the A64 or DP64. So, if the errata are complete and the A64
doesn't have this problem, you might verify that CLKSW is configured
to zero in your debugger and see if that works.

If the errata AREN'T complete - if this bug appears on the A64 as
well - then you need to set CLKSW. Then, when your software enables
the PLL the debugger should detect that it can no longer talk to the
target. At that point, it could ask you for a new bus frequency, try
one that you have previously configured, or just give up.

I don't know which of those P&E's debugger does, but you might dig
through their configuration dialogs and documents to find out.

My debugger, NoICE, will show a dialog asking for the
new bus/BDM frequency. Then on subsequent runs, it will try that
frequency automatically without asking. Since my reading of the
errata shows this bug not present in the A64, NoICE won't set CLKSW
by default, but the configuration can be changed if necessary.plug>

Best regards, John Hartman
NoICE Debugging Tools
http://www.noicedebugger.com
At 20:24 10/27/2007 -0500, you wrote:
>As Edward suggests the MODE register would let your software tell
>whether it is being debugged.
>Are you sure that the debugger can't be configured to deal with this?
>...But some MC9S12 (the A256 and DP256 in particular) had/have a bug:
>BDM Loses Sync when Using PLL at High Frequencies
>When using the BDM constant clock source, i.e. CLKSW=0, with the PLL
>engaged, PLLSEL=1, and the PLL multiplier greater than or equal to 2, the
>BDM can lose communication with the host system.

This is the A64. It is behaving like you describe... if I set the
PLL to a multiplier of 2 or greater, then it looses comm. [If I
don't have CLKSW=1 then it won't ride across ANY change in clock speed.]

Unfortunately, the workaround won't work. Once the P&E drops comm,
the ONLY option it seems to offer me is to issue a RESET to the
processor. That puts me back to the beginning.

Fortunately, the board itself works just fine at the higher
speed. It's just the debugging that's broken.

tnx, jmk
-----------
James M. Knox
TriSoft ph 512-385-0316
1300 Koenig Lane West fax 512-371-5716
Suite 200
Austin, Tx 78756 j...@trisoft.com
-----------
James M. Knox wrote:

[...]

> This is the A64. It is behaving like you describe... if I set the
> PLL to a multiplier of 2 or greater, then it looses comm. [If I
> don't have CLKSW=1 then it won't ride across ANY change in clock speed.]
>
> Unfortunately, the workaround won't work. Once the P&E drops comm,
> the ONLY option it seems to offer me is to issue a RESET to the
> processor. That puts me back to the beginning.

IMO it's no fun to debug at another speed than the product is running
in reality.

I suggest to drop the incapable debugger and use NoICE - it's not
expensive and works very well (didn't test the HC12 variant but used
it for HC08 development some time ago).

Oliver
--
Oliver Betz, Muenchen
James M. Knox wrote:

[...]

> >I suggest to drop the incapable debugger and use NoICE - it's not
> >expensive and works very well (didn't test the HC12 variant but used
> >it for HC08 development some time ago).
>
> When I first started running into these PLL problems I got the same
> suggestion. I looked at NoICE, and agree that it is well worth
> investigating. But in the middle of a high-pressure-schedule project
> doesn't seem like a good time to switch horses. So I need to get

I see no problems by doing so. NoICE isn't hard to understand, you
should get it working in a couple of hours. Maybe it's less effort
than debugging at different speed. Give it a try!

Another idea: use another 9S12 derivative (without the PLL bug), and
a superset of peripherals. I don't know whether for the A64 exists a
compatible "superset" derivative. And likely it's more expensive and
more work than using NoICE.

Oliver
--
Oliver Betz, Muenchen
At 17:25 10/29/2007 +0100, you wrote:

>Another idea: use another 9S12 derivative (without the PLL bug), and
>a superset of peripherals. I don't know whether for the A64 exists a
>compatible "superset" derivative. And likely it's more expensive and
>more work than using NoICE.

I'm shipping prototypes on Thursday, and pre-production units in 30
days. I *really* want to minimize changes until then.

jmk
-----------
James M. Knox
TriSoft ph 512-385-0316
1300 Koenig Lane West fax 512-371-5716
Suite 200
Austin, Tx 78756 j...@trisoft.com
-----------
At 10:25 10/29/2007 +0100, you wrote:

>IMO it's no fun to debug at another speed than the product is running
>in reality.

Agreed. Worst case, you hit timing problems that only occur at the
higher speed, and won't fail at the lower.

>I suggest to drop the incapable debugger and use NoICE - it's not
>expensive and works very well (didn't test the HC12 variant but used
>it for HC08 development some time ago).

When I first started running into these PLL problems I got the same
suggestion. I looked at NoICE, and agree that it is well worth
investigating. But in the middle of a high-pressure-schedule project
doesn't seem like a good time to switch horses. So I need to get
through this thing (if I can) before I look at a new debugger
software and hardware.

jmk
-----------
James M. Knox
TriSoft ph 512-385-0316
1300 Koenig Lane West fax 512-371-5716
Suite 200
Austin, Tx 78756 j...@trisoft.com
-----------