68HC1 | 812A4 | 9S12DP256 | Bootloader | CodeWarrior | D60A | Debugger | DP256 | ECT | EEPROM | EVB | Flash | HC1 | HCS12 | I2C | IAR | ICC1 | Interrupts | LCD | M68KIT912DP256 | MC9S12DP256 | MC9S12DP256B | Metrowerks | Motor | MSCAN | Multilink | PLL | Quadrature | SDI | SPI | Transceiver | XFC

--- In 6...@yahoogroups.com, Donald E Haselwood
wrote:
>
> Does the following indicate the flash is bad (or is it something
else)?
>
> Part: MC9S12E128CPV Mask 2L15P
>
> I built 6 boards with this part, partially populating the boards so
that there
> are only the by-pass & pll capacitors and resistors and MAX232C
with it's
> caps. All but one of the boards work normally. This one "bad"
board, via
> the BDM and pod (9S12BADGE) responds normally except the Dbug-12
command
> FBULK hangs. I can write/read SRAM OK. DEVICE command shows the
correct
> device. Flash appears erased (the processor is new), but FLOAD
doesn't load
> anything. It's the first time I've run into this.
>
> Is this a processor with defective flash, or are there other things
that can
> cause the flash with Dbug-12 not to work? It's no big deal, i.e.
toss the
> board into the bin, but I'm curious if there might be another
answer.
>
> Don
>

My guess would be a problem with the PLL. Maybe a short on the XFC
pin or not properly bypassed Vddpll?
Try doing a FBULK ;np so it does not use the PLL when it tries to do
the FBULK. On a related note you can also use that ;np with the FLOAD
command.
If it works with the ";np" parameter then I would look closly at the
voltage on Vddpll and the XFC pin.

Regards,
Darci

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )

>
> My guess would be a problem with the PLL. Maybe a short on the XFC
> pin or not properly bypassed Vddpll?
> Try doing a FBULK ;np so it does not use the PLL when it tries to do
> the FBULK. On a related note you can also use that ;np with the FLOAD
> command.
> If it works with the ";np" parameter then I would look closly at the
> voltage on Vddpll and the XFC pin.
>
> Regards,
> Darci

Darci,

Thanks! Your suggestions were exactly on-target. Both FBULK and FLOAD
worked with ";np" I then found that the cap between Vddpll and XFC had a
solder bridge ( little solder smeared across the top of the 0603 10 nf cap)..

Problems with the pll was something I had not considered. I had checked the
voltages and by-passed power pins and they were all OK. Thanks again for the
tip. That's one to remember.

Don



(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.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. 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
-----------------------------------------------



(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.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.

Best regards, John Hartman
NoICE Debugging Tools
http://www.noicedebugger.com
[Non-text portions of this message have been removed]

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.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.

Best regards, John Hartman
NoICE Debugging Tools
http://www.noicedebugger.com
[Non-text portions of this message have been removed]



(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.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
-----------------------------------------------



(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.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



(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.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
-----------------------------------------------



(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )