555 BDM startup problem

Hello, we are having a strange problem with a new MPC555 design that 
we are trying to debug, and we could sure use some suggestions. This 
is our second 555 design, and since the first one was quite 
successful, we thought we knew our stuff, but apparently not. We can 
only seem to start a successful BDM debug session approximately once 
every several hours. Every morning I power up the Abatron BDM pod, 
then the 555 board, then click on  CodeWarrior V8  Project…Debug. 
The initialization file executes, then the program downloads, and I 
can begin debugging.  If I then power cycle everything and start 
over, the debug session fails during the initialization file 
execution, as various register writes fail. The failures repeat 
every time, although at apparently random places during the register 
initialization, unless I leave everything powered off for several 
hours. This happens on both of the new boards we are trying to bring 
up. We have tried the initialization on two different laptops, and 
two different BDM pods, with no change in behavior. I can take the 
same initialization file, laptop, and Abatron BDI BDM I/F, and go to 
our first 555 design board, and download code every time.

We have looked at everything we can think of, and consulted every 
manual and app note we are aware of, to no avail. In particular, we 
have verified:

We are using an external crystal, running at 20 MHz. With BDM not 
connected, our CLKOUT is 20.0MHz. With the BDM attached, but before 
we attempt to start the debug session, our measured CLKOUT is still 
20.0 MHz. Once we try to debug and fail, CLKOUT is still 20.0 MHz, 
and ENGCLK is 10Mhz.

*HRESET and *PORESET are not pulsing, and in fact look very solid. 
With the BDM pod attached, on *HRESET, we see a 1ms negative going 
pulse (reset) at an interval of approximately every 6.8 seconds. 
After we attempt a debug session and fail, we no longer see the 
periodic *HRESET. I suspect this is because the initialization 
typically gets far enough to disable the watchdog. With the pod 
detached, we see the *HRESET every 6.8 seconds (no code downloaded 
to flash yet). 

The entire board is drawing less than 200mA. The power supply looks 
very clean. KAPWR is at 3.326V with an approx. 50mv peak to peak 
ripple on it. VDDSYN is 3.345 Volts with approx. 30mV ripple peak to 
peak.

The MODCLK pins are configured as MODCLK1 = 0, MODCLK2 = 1, MODCLK3 
= 1. We don't use the MODCK pins for anything else, so they are tied 
high or low through a 4.7K resistor. 

We have tried TRST in two configurations: 1) tied low and 2) pulsed 
low at power up, and then held high. Neither configuration seemed to 
make a difference.

XFC is coupled to VDDSYN via a capacitor. VDDSYN (and KAPWR) do not 
significantly lag VDDL/VDDi. We have a 10 ohm resistor in series 
with VDDSYN, but we seem to get PLL lock every time. In general, PLL 
lock does not seem to be the issue here. We do not have a meaningful 
DC offset on VDDL/VDDi prior to powering up.

RSTCONF is either tied high or low through a 4.7K resistor depending 
on which config word we are trying to use. The external reset 
configuration word is driven on the bus with the *HRESET signal.

The mask set on the 555 chip appears to be K3, as the following is 
written on the part:
MPC555LFMZP40
UQQAJ0431

We have tried configuring the board to fetch it's H/W reset config 
word both from the bus (value listed below), and from shadow RAM 
(value 0x20400000). Neither configuration seems to make a 
difference. During one of the board's brief periods of lucidity, I 
was able to program the shadow RAM with the above value.

The external H/W config word is as follows:  D0 – D5  are driven 
low, D6 – D8 are not driven, D9 – D14   are driven low, D15 is not 
driven, D16 is driven low, D17-D18 are driven high,D19 is driven 
low,D20 is driven high D21-D23 are driven low,D24-D27 are not 
driven,D28-D31 are driven low.

The initialization file I am using sets the registers as follows:

MSR		0x00003002
IMMR		0xFFF00800
BBCMCR		0x00000000
SIUMCR		0x00006000	; single chip mode
SYPCR		0x0000FF88	;  Disable watchdog
DPTMCR		0x0000		
RAMBAR		0xFFA0		
PORTQS		0x0000		
PQSPAR/DDRQS	0x0000		
MPIOSMDR	0x0018		
MPIOSMDDR	0xFE7F	
MIOS1TPCR	0x0001		;alt function for VFLS pins
SRAMMCR		0x00000000	
SGPIODT1	0x00000000	
SGPIODT2	0x00000000	
SGPIOCR		0xBB00FCFF	
EMCR		0x00000000	
UMCR		0x00000000	
PLPRCR 		0x00104000    ;external 20Mhz, run internal at 40 MHz

Thanks  in advance for any suggestions!

Chuck Smith, Stara Technologies, Inc.








------------------------ Yahoo! Groups Sponsor --------------------~--> 
Get Bzzzy! (real tools to help you find a job). Welcome to the Sweet Life.
http://us.click.yahoo.com/A77XvD/vlQLAA/TtwFAA/dN_tlB/TM
--------------------------------------------------------------------~-> 

-----------------------------------------------------------
To learn more about Freescale Microcontrollers, please visit
http://www.freescale.com/mcu


 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/MPC500/

<*> To unsubscribe from this group, send an email to:
    [email protected]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/