MC68020 Embedded System HW Reset Problem - Need Help
Jim Flanagan
Hi -
I am hoping that someone could give some pointers as to how
and attack a reset (double bus fault) problem with an embedded
68020 board that was originally designed by HP in a piece of
test equipment that was mfg back in 1996. Since HP no longer
supports this equipment, I'm on my own. I do have the schematics,
however.
Problem:
There are times when the unit is powered up, that the 68020 will not
reset properly and simply locks up. Upon investigation, I have
determined that a double bus fault has occurred. There is a diagnostic
led on the HALT line that shows this to be the case. This lockup occurs
randomly on power up. I have two of these units, one unit exhibits this
problem where the other does not. Both units are running the same ver
of firmware that is mature. I'm convinced that the problem must be
hardware related.
What I've done:
The unit uses a TI supervisory reset part (TL7705) that has a reset
delay of 120mSec (I'v verified this). I've used a digital storage scope
to capture the rise time of the 5V power source, the reset line to the
68020, and the 68020 clock. All three signals behave as expected. The
osc starts up within about 5 mSec, the 5V supply within about 1mSec and
the reset pulse is approx 120mSec. However, about every dozen or so
power cycles, the processor will double bus fault and lock up. The osc,
by the way, is at 19.6MHz.
Originally, I thought that the power supply was coming up in a strange
manner or the TL7705 was malfunctioning, but I don't see it.
I need someone with 68000 HW design experience to give me some pointers
as to how and solve this. Any help would be appreciated.
Thanks
Jim
Gene S. Berkowitz
jf...@tampaREMOVEbay.rr.com says...
Check the rise time of the reset; it must be less than 1.5 clocks.
Does the board have an MMU, FPU or external cache SRAM? Such a device
may be issuing a bus cycle termination, which will result in BERR/HALT.
You might try disabling the internal cache by asserting CDIS.
Have you verified that the '020 is a 25 Mhz part, and not the 16 MHz
version, which _might_ be capable of running at 19.6 MHz?
--Gene
Didi
> ....
> There are times when the unit is powered up, that the 68020 will not
> reset properly and simply locks up. Upon investigation, I have
> determined that a double bus fault has occurred.
Most likely the reason for the double bus fault is some problem
during reset code execution. May be some memory or peripheral
does not respond (does not assert the DSACKx line(s) etc.).
A very likely reason would be some "forgotten" bit in the flash or
eprom;
if the 68020 tries to access a non-decoded address during reset
and gets a BERR, here you go, it will halt because of a double bus
fault.
Dimiter
------------------------------------------------------
Dimiter Popoff Transgalactic Instruments
http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/
Original message: http://groups.google.com/group/comp.arch.embedded/msg/60bec024c19a42e7?dmode=source
Jim Flanagan
time permits. I first need to study up on what the MMU, FPU is?
I have no experience with the 68000 uP, only Intel products. I figured
the problem was likely straight forward but it is looking to be more
subtle. If I emailed you the schematics would you be willing to
give me your opinion?
Thanks, again
Jim
Dave
>
> Gene S. Berkowitz wrote:
>> Check the rise time of the reset; it must be less than 1.5 clocks.
>> Does the board have an MMU, FPU or external cache SRAM? Such a device
>> may be issuing a bus cycle termination, which will result in BERR/HALT.
>>
>> You might try disabling the internal cache by asserting CDIS.
>> Have you verified that the '020 is a 25 Mhz part, and not the 16 MHz
>> version, which _might_ be capable of running at 19.6 MHz?
>>
>> --Gene
>>
>>
> Thanks for the tips, Gene. I will look into these areas tonight, if
> time permits. I first need to study up on what the MMU, FPU is?
> I have no experience with the 68000 uP, only Intel products. I figured
> the problem was likely straight forward but it is looking to be more
> subtle. If I emailed you the schematics would you be willing to
> give me your opinion?
> Thanks, again
> Jim
MMU
Memory Management Unit. There is one built into the '020. It will be
disabled by reset. I don't see the MMU causing a problem at reset.
FPU
Floating Point Unit. None built-in, however there may be an external
one. Look for a chip marked 68881 or 68882, probably adjacent to the
CPU. My first thought is that an FPU can not cause a double bus fault,
but I can't remember the connections, so I'll say 99.9% certainty. And
it would be very strange since the problem is intermittent.
The internal cache shouldn't be an issue since it will be cleared by the
reset. With the internal cache (256 bytes), I don't know that HP would
have included an external cache--adds a lot of complexity (especially
considering the internal MMU).
After RESET~ goes inactive, there will be two or four fetches from
memory depending on whether the memory is 16- or 32-bit. The first 1/2
will fetch the Supervisor Stack Pointer (SSP) and the next 1/2 will
fetch the Initial Program Counter (IPC). Both values must be even. The
CPU will attempt to fetch the instruction at the address given by the
IPC. An odd address or an active BERR~ signal will cause a halt at this
point. If everything is good, I believe the only thing left is an
address or bus error during the execution of the first instruction.
Note that until the first instruction after reset is executed, it only
requires one error (address error or active BERR~) to cause a double bus
fault. After this first instruction, it requires two errors and the
second must occur during processing of the first instruction of the
first error. I think, but am not 100% certain for the '020, that the
double bus fault can be triggered by a bus error while executing an RTE
on a bus error stack frame. I may be mixing my CPUs on this one.
Do you have a logic analyzer you can use?
DaveT
Dave
>
> MMU
> Memory Management Unit. There is one built into the '020. It will be
> disabled by reset. I don't see the MMU causing a problem at reset.
>
>
> The internal cache shouldn't be an issue since it will be cleared by the
> reset. With the internal cache (256 bytes), I don't know that HP would
> have included an external cache--adds a lot of complexity (especially
> considering the internal MMU).
Oops! The '020 did not have a built-in MMU, that was the '030. HP
might have included an external MMU, but it adds considerable cost and
complexity. External cache to go with it? Adds more cost and complexity.
DaveT