Yahoo Groups archive

68300

Index last updated: 2026-04-29 00:01 UTC

Message

RE: [68300] 3.3V 68LK332 reset problems

2002-11-01 by Melear Charles-rdph40

Allan,
 
What are you doing to my parts???????
 
OK, for starters, you state that you are using a 40 KHz drystal.  That should give you a clock out frequency of 40,000 * 256 or 10,240,000 or 10.24 MHz.  So, it appears that your oscillator is starting and everything is OK there.
 
Now, you also say that the RESET pin is cycling every 12.5 milliseconds.  This is also typical operation, that is, if something is wrong, the Watchdog will time out every 12.5 ms with a 40KHz crystal.
 
Now, you state that CS Boot pulses are 200 ns.  This sounds fishy.  At a system clock frequency of 10.2 MHz, a clock period with worth about 100 ns.  Now what I suspect is that your measurement might be a little on the approximate side and the period of CS BOOT might be a little longer.  
 
Now, CSBOOT should have a pulse width of about 2 1/2 system clock cycles IF  (did you see that big IF) the system was running 3 cycle (zero wait state) memory accesses.  So, with a 10 MHz system clock and zero-wait states, you should expect a CS BOOT pulse of about 225 - 250 ns.
 
BUT, this is NOT (I repeat KNOT) correct behavior.  CSBOOT should have 13-wait states from the release of reset.  So, why are you seeing a pulse width that indicates zero wait states?
 
You probably are letting one or both of the DSACK lines float and if one or both or either of the DSACK lines float low, they will cause all external memory accesses to be zero wait states.
 
Go check your DSACK lines and make sure that they are pull-up.  They must not be low (or floating) even for a few cycles after the release of reset.  Otherwise you will get memory cycles that are much shorter than expected.  
 
However, what is even worse, you could get an "8-bit" DSACK when you are expecting a "16-bit" DSACK or vice-versa.  This really messes things up.
 
So, pull those DSACK lines up and let me know how things go then.
 
Regards,
 
Charlie

 
 
 
 -----Original Message-----
From: Allen Nance [mailto:anance@...]
Sent: Thursday, October 31, 2002 5:47 PM
To: 68300@yahoogroups.com
Subject: [68300] 3.3V 68LK332 reset problems



Hello Group:

      I have a new design with the 3.3V 68LK332 part. I have not used the 3.3V
part before but have used the 68332 extensively. The problems I am having 
are at power up.

1. When I apply power the part comes up most of the time. (80%)

2. When I add a power-up reset chip MAX690, the part never resets correctly.
      The '332 is reset cycling about every 12.5 msecs.
      The CLKOUT pin is at about 10Mhz (I use at 40kHz crystal)
      At reset the CSBOOT is accessing ROM with a pulse width of 200nsec 
for about
       60 cycles and then quits.
       The MAX690 is pulling RESET low about every second for about 200msecs
       (this is the MAX690 watchdog timeout)

3. I read a while back about decreasing the size of the series resistor for
3.3V applications, so I tried that but still no luck.

I am puzzled why it would come up OK with a straight power up but not
with a power-up reset monitor.

Any thoughts out there?

Allen Nance




Yahoo! Groups Sponsor	

ADVERTISEMENT
 <http://rd.yahoo.com/M=237459.2482214.3917349.2146399/D=egroupweb/S=1706554205:HM/A=1267611/R=0/*http://ad.doubleclick.net/jump/N2524.Yahoo/B1071650;sz=300x250;ord=1036107852620560?> 	
  <http://us.adserver.yahoo.com/l?M=237459.2482214.3917349.2146399/D=egroupmail/S=:HM/A=1267611/rand=989960542> 	

---------------------------------------------------
To unsubscribe from this group, send an email to:
68300-unsubscribe@yahoogroups.com

To learn more about Motorola Microcontrollers, please visit
http://www.motorola.com/mcu <http://www.motorola.com/mcu> 



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




[Non-text portions of this message have been removed]

Attachments

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.