MC68020 Embedded System HW Reset Problem - Need Help

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

Reply to
Jim Flanagan
Loading thread data ...

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

Reply to
Gene S. Berkowitz

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

formatting link

------------------------------------------------------

formatting link

Original message:

formatting link

Reply to
Didi

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

Reply to
Jim Flanagan

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

Reply to
Dave

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

Reply to
Dave

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.