Re: MC68020 Embedded System HW Reset Problem - Need Help

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



.

Relevant Pages

  • Re: PowerBasic rocks!
    ... Modern DRAMs are essentially wide-word block-transfer devices, ... output values located in data cache. ... no need for the bus width to match the word size. ... 64-bit memory bus; many graphics cards use a 256-bit memory bus. ...
    (sci.electronics.design)
  • Re: PowerBasic rocks!
    ... Modern DRAMs are essentially wide-word block-transfer devices, ... output values located in data cache. ... no need for the bus width to match the word size. ... 64-bit memory bus; many graphics cards use a 256-bit memory bus. ...
    (sci.electronics.design)
  • Re: [PATCH 00/10] AXFS: Advanced XIP filesystem
    ... The NOR is not on the RAM bus, ... I'm not sure if cache is an option with this device - but would it ... ARM's cache and see if that speeds up streaming read time. ...
    (Linux-Kernel)
  • Re: Microblaze data cache question
    ... >> I would insert multichannel opb sdram controller into a project. ... >> I would use xcl bus to access read/write datas into a integer matrix. ... >> 2) init cache with address of matrix element ...
    (comp.arch.fpga)
  • Re: memory reading and writing
    ... There is a penalty on the first access - a cache miss - as the ... memory bus speed...or that RAM would cost more, ... of system functionality off-chip and such are all about: The CPU ... as the AGP card is on the same bus as the memory as ...
    (alt.lang.asm)