hi, i had got a luck to repair A board with a bad 6502 MPU. uh... after tracing back and forth of course. i wanna to ask if there is a way to know if the culprit on the arcade board or whatever board with mpu inside was the culprit.

like, what is minimally needed by a mpu to start working/pulsing? the 6502 for instance, have Addr Bus and Data Bus and several control pin. i was facing with another board that have the clock pulsing and it seems other control pin was ok, i.e reset pin. Am i miss something here?

gosh, i was replacing a big mpu 68k today, and guess what!! i dont change anything :mad:
Posted on 2003-05-02 07:01:49 by dion
In the past, I rarely found the problem to be the cpu. Check to see if an interrupt line is being held low constantly or a 'wait' line. With a scope, when you press reset, do you see any activity, however briefly, on the data lines.
Posted on 2003-05-02 07:53:12 by drhowarddrfine
yes, i think its rare. uhmm... int pin, eh? yup, yup, need to check that one.

i was thinking that mpu need a rom and ram, am i right? now, if one of them was fail, whatever the fail is , would the mpu working/pulsing?
Posted on 2003-05-03 07:00:06 by dion
Hi, dion,

What makes a microcontroller different from a microprocessor is the fact that in general it has ROM, RAM and I/O ports built-in.
So you will no longer see the familiar address/ data/ control busses. The entire computer is inside the chip.
You are dealing now with I/O ports, which can be configured (internally through software) as either inputs or outputs.
You need to look closely at the schematic and see if an I/O point is used as input or output. (If it's connected to the output of a gate for example, almost certainly it's an input, and so on).

If the micro doesn't work, first check th I/O lines and make sure the signals are correct, based on what the I/O points should be (inputs or outputs) and their normal state for operation.
Some of the lines can be stuck at Vcc or GND. Now these being I/O lines, the microcontroller may in fact be working inside, but it may be waiting for one of these signals to go HIGH or LOW, so it will appear that it is not working.
I found microcontrollers where everything was working, but one of the I/O lines was damaged and stuck to ground so just that one feature was not working.

Hope this helps a little.
Posted on 2003-05-05 12:03:36 by VVV
thanks for that explanation, VVV :grin:

uhm... i still cant determine though, i facing many 68K processor, a DIP 60? or 68 pins, dont remember it, what i know is, it is the biggest chip afaik. i found many faulty board which is no pulsing on the data/addr bus of the 68k. but, i notice that most of them having /IPL1 was low. and i try to trace back, but geeh!!!, i lost the trace behind the chip, dont know where he go :mad: my final effort was trying to test from nearest pin, if i can get to what it is connected. but... it failed, and i'm so down, and discourage :(
Posted on 2003-05-06 08:13:26 by dion
Hi, dion,

I did not realize it was actually a 68K processor. In that case all my previous ramblings do not apply.
You will need to look at the obvious signals:
Correct power?
Clock present?
Reset correct state?
Hold correct state?
Any activity on the address bus?
Is the micro attempting to read anything? is the READ signal being asserted?
Do you see the ROM being accessed?
And so on.

I would also use a reset button and reset the micro periodically, while probing pins. Does it appear to start after reset and get stuck? This could provide some clues.

I am sorry I cannot be any more help.
Posted on 2003-05-06 19:07:38 by VVV
the power line was not an issue, i though, because i testing it in my bench. i'm always check the clock existance, pin 15 . the reset at pin 18, in normal is high, and it is, although i found one board with this pin low, and seeing chip MB87???, sorry forgot it.

hold pin? uhm... maybe i should read the pinout again ;) addr bus and databus checked too :D

unfortunately, the r/w pin is low, most of them iirc.
hmm... how to see the mpu accessing the ROM??
with see its addr bus, isnt it? or with r/w pin?

and your last tip, yeah! i do it sometime. but, thanks you remind me about this one. i found one, that when start all pin reacting ok, aka pulsing. but shortly after, all pin get stuck state. and i can figure out that the picture is somehow showing static garbage.

anyway, thanks, you had help me, i need to push myself more harder on this
:mad:
Posted on 2003-05-08 05:47:15 by dion
Hi, dion,

The line I meant is actually /HALT. Anyway, if some device drives is low, this will stop the processor.
Also, if there is a bus fault, the processor will drive it low. So, check this line. It should be high.

Check the /BR signal. If it's low it means some device requested the bus and that is why the processor stopped.

The R/W pin being low tells you the micro is trying to write to some device. But I would check to make sure the pin is not actually pulled low (stuck), because this could be the problem.

To see if the micro is accessing the ROM, check the /CS and /OE of the ROM. They should go low sometimes, but should not be stuck low. If the ROM is in a socket please check it carefully. Sockets are a major source of trouble. Sometimes it helps just to remove and reinsert the ROM into the socket. If possible, try to replace the ROM with a known good one. If the firmware is corrupted, that can have effects like these.

From what you are describing, it seems the micro is attempting to start and then it gets stuck.
Probe the /BERR signal. If it goes low, this tells you there is a bus error in the current cycle. Then you know the micro is actually working but something else is wrong.

Please try to describe the board, what it contains, maybe that will give me some clues.

Good luck.
Posted on 2003-05-09 20:17:23 by VVV
hi VVV, i see you're so seasoned in this stuff, great thanks for the tips :grin:

btw, i need to take some time to digest what you said and doing it. oh, and would you know if i mention arcade board name here? or what do you mean for me to describe the board?

thanks
Posted on 2003-05-10 08:28:26 by dion
Hi, dinon,

Well, I had my share of debugging boards. But it seems there is no easy way to fix them.

What I meant was if you could tell me a little more about the board:

Actual uP used
what kind of ROM it uses
what kind of RAM
Does it have any I/O ports? Other peripherals?
Things like that. Unfortunately the name Arcade doesn't ring a bell. I searched the net for it and it only comes up as game. Is there a connection?

Best regards,
Posted on 2003-05-13 11:33:56 by VVV
Hi, dion,

I thought I'd post this link. Maybe you get lucky and find your schematic. Then we can talk.

http://www.geocities.com/SiliconValley/Horizon/2253/arcade.html

Good luck!
Posted on 2003-05-13 11:45:40 by VVV
As you state is it "pulsing" ? Yes that is the first place I would begin. Make sure you have a clock. Then check all address and data lines. You may have to keep reseting the processor by cutting power probably. That way you can observe if the processor is reading memory and executing instructions.
Posted on 2003-05-18 17:49:06 by mrgone
Hi guys,

I'm new to the board and just thought I would put in my 2 cents worth on a subject I used to be pretty good at.

We're talking old technology here.

From the sound of things, you have a clock and uP activity till it locks. The buss buffers on these old systems are very static sensitive, so along with all the other obvious things to check are the signals through the buffers.

And yes, socketed chips are a major cause of problems. When you pull them be careful of static, clean the pins with a soft eraser, and reinsert them making sure all the pins insert properly.

Hope this tip helps.
Posted on 2003-05-19 14:55:58 by djinn
great thanks guys :alright:

djinn: welcome :) thanx for putting your 2 cent for giving us tips :D btw, i know that tips already , but as time going through, i need to earn my experience by myself. guess what, actually i dont want to say it too early, but checklist from VVV has pass, and lo, the board still dont work.
Posted on 2003-05-20 05:56:35 by dion
Dion,

I can relate with your difficulties. CPU boards can be a bear to troubleshoot.

Does your board have a battery on it for any memory retention? If so, it may also have a circuit that is usually referred to as a 'watch dog timer', which is used to pulse the battery and make it last longer. If something goes wrong in that circuit, it can prevent the entire system from working properly.

Good Luck,
Djinn
Posted on 2003-05-21 10:57:35 by djinn
Hi, dion,

I take it the link I posted did not help you find the schematic for your board.
Can you tell the model, type, any numbers on the board? Anything that would help identify it?
Maybe something will just "click".
Posted on 2003-05-21 11:34:24 by VVV
djinn: hi djinn, afaik that watchdog timer was used to inform processor that everything is allright, i.e. bus/ram/rom/whatever. i'm neva read that it related to batt . instead, watchdog timer no need a batt to operate, because it no need to operate in power off situation. but, if theres a batt in the board, what i know is the baord keep a ram/ a piece of memory to be used for saving setting values, or in the CPS1-2 systems, its used for decrypting the roms/programs.

VVV: hi VVV, i think i cant do that, because the board has been sent back to the owner :( it mean i can do nothing with it. as you mention about arcade, its not a name, but its a term for games produced in 70/80's . well, thats not mean its not produced anymore. recent product uses smd alot. thanks for asking me further, i thought we could continue this thread like what the subj is, tips for troubeshoot mpu, shall we discuss it more detail, or made a tutorial maybe. btw, the board is cadillac & dinasour, not a cps type board. i saw every modified/botleg board using the same 68k processor.
Posted on 2003-05-22 06:15:30 by dion
Dion,

thnx for reminding me, the watch dog timer was used as you say also. Motorola used it in a lot of their equipment boards because they didn't want the system doing strange things if the battery backed ram was lost.

Examples include MIR series of weather station controllers, Centracom series dispatch stations, early cell site controllers, and others.

Djinn
Posted on 2003-05-22 10:22:37 by djinn
Hi, guys,

I just want to make comment here on watchdogs, resets and battery backed-up RAM. I sense some confusion.

A watchdog is actually a timer. When it overflows it resets the microprocessor (or microcontroller; in modern micros, it can also just generate an interrupt).
If the microprocessor operates correctly, then under program control it will periodically clear the timer, not allowing it to overflow and generate a reset.
If there is something wrong with the program, if the micro gets stuck (because it read some bad data, or... something weird happened ), it cannot clear the timer, the timer overflows and resets the microprocessor. Kind of like your resetting the computer when it's "frozen".

A battery backed-up RAM is used to store data and retain it even when power is lost. To do that it needs a circuit that senses the power is about to be lost and switches over to a battery. That is a battery switchover circuit.

A reset generator is a circuit which senses the supply voltage and as soon as it goes below a certain level, it resets the micro and it keeps it in reset until the voltage reaches normal operating value. That prevents the micro fom operating with a low supply voltage, which could cause malfunction. The reset circuit also includes some sort of delay or timing circuit, which ensures that once a reset is generated, it lasts long enough, typically 100~200msec. That ensures the micro gets a good reset, not just a thin spike, even if the supply voltage recovers very quickly. This delay is necessary for the micro's oscillator to start-up and stabilize before any instructions are executed. This circuit inherently works at power-up. When you switch on the power, the voltage increases rather slowly, but the reset circuit keeps the processor in reset until the supply voltage reaches the correct value. It's really a comparator with hysteresis, followed by a timer.

The confusion I think arises from the fact that some manufacturers packed the watchdog timer, the reset generator and the battery switchover circuit in a single package. (An example is Linear Technology's LTC694). This makes a lot of sense, because once the power is about to be lost, two things have to happen: reset the micro and back-up the RAM. So the sense circuit can be shared. Also, whether the reset is generated by the watchdog or by the undervoltage, it makes no difference, a 100~200ms signal has to be generated, so again some circuitry is shared, including the reset output pin.

I hope my little dissertation here helps clear up some things.
Posted on 2003-05-22 11:43:10 by VVV
Hi VVV,

EXCELLENT explanation. That's exactly what Motorola did was package everything and call it a watch dog timer. I had forgotten and it's been awhile since I've seen one.

Thank you,
Djinn
Posted on 2003-05-22 16:36:26 by djinn