MC68020 Embedded System HW Reset Problem - Need Help

In article <483e1594$0$30498$4c368faf@roadrunner.com>,
jflan@tampaREMOVEbay.rr.com says...
>
> 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

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

Jim Flanagan wrote:
> ....
> 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_tg...7600228621276/

Original message: http://groups.google.com/group/comp....7?dmode=source

Gene S. Berkowitz wrote:
> In article <483e1594$0$30498$4c368faf@roadrunner.com>,
> jflan@tampaREMOVEbay.rr.com says...
>> 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
>
> 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

Jim Flanagan wrote:
>
> 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 wrote:
>
> 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